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I have accepted this Space Station Operations Task Force (SSOTF) 
report as a reference point from which to implement the Program's 
concept for operations. It is clearly a thoughtful and extensive analysis 
of key Space Station Program parameters. 

At this time, the Program has started the detailed work of preparing 
the necessary program documentation, the operations capability 
requirements, the instructions to contractors, the agreements with 
other organizations, and the refinement of the management tools 
required to effect the implementation. 

The Space Station Program will carefully review all SSOTF recom- 
mendations. This review will involve all relevant NASA organizations. 
I anticipate that a large portion of the recommendations will be 
approved and implemented. However, because of the extensive 
number and the implications of the Task Force recommendations, it 
should be expected that not all will pass this final screening. 



AndreW J. Stofan 
Associate Administrator 
for Space Station 
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I have accepted this Space Station Operations Task Force (SSOTF) 
report as a reference point from which to implement the Program's 
concept for operations. It is clearly a thoughtful and extensive analysis 
of key Space Station Program parameters. 

At this time, the Program has started the detailed work of preparing 
the necessary program documentation, the operations capability 
requirements, the instructions to contractors, the agreements with 
other organizations, and the refinement of the management tools 
required to effect the implementation. 

The Space Station Program will carefully review all SSOTF recom- 
mendations. This review will involve all relevant NASA organizations. 
I anticipate that a large portion of the recommendations will be 
approved and implemented. However, because of the extensive 
number and the implications of the Task Force recommendations, it 
should be expected that not all will pass this final screening. 



Andrew J. Stofan 
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DEFINITION OF KEY SSOTF TERMS 

This Summary Report uses a standard set of terms 
established by the Task Force as a basis for developing 
the description of the proposed operations framework 
for the Space Station Program. These terms and 
definitions will become evident as the reader reviews 
this document. However, due to the number of 
organizations and professional disciplines represented 
by the SSOTF's various participants, the terms may be 
used differently than the reader is normally acquainted 
with. Hence, a definition of key terms used by the Task 
Force follows as an aid to the reader in understanding 
the text. A more comprehensive Lexicon is included as 
Appendix D of this report. 


• Space Station Program, Space Station, Station 
Program, the Program and Station: These terms 
are used synonymously and should always be 
interpreted as global in nature, each encompassing 
all of the component parts of the Program, manned 
and unmanned, both in space and on the ground. 

• Space Station Operations: This term refers to all 
of the ground and space based activities required to 
operate all components of the Program, up to and 
including the operational interfaces with the user 
community. 

• Program Phase Definitions: The Station 

Program is composed of two major phases of 
operations: development (encompassing system 
design, assembly, and operational verification); and 
mature operations (encompassing system 
utilization and evolution). These two phases 
naturally overlap due to the progressive build-up of 
orbital capability and are more specifically defined 
as follows: 

1. Station Development Phase: This term 
applies to the period of time commencing with 
the Program management approval to develop 
and deploy the baselined Space Station 
elements. It is characterized by several 
overlapping sub-phases including: "operating 
system" requirements definition; design; 
implementation (construction); integration; 
acceptance testing; product delivery (including 
on-orbit assembly of Station elements); and 
product verification (on-orbit test and checkout). 
The Station "operating system" is defined to 
include the total complement of hardware, 
software, and personnel support capabilities 
(ground and on-orbit) required to proceed 
through the various sub-phases. 

2. Station Mature Operations Phase: Defined 
as the period of time commencing with the 
completion of assembly and on-orbit verification 
of a complement of Station elements sufficient to 
sustain a permanent manned presence in orbit. 
It includes the capability to routinely schedule 
useful payload operations activities among any 
remaining Station assembly tasks. Mature 
Operations are gradually phased-in as 
additional Station components are assembled 
and a full operational capability is achieved. It 
is also characterized by continuing plans for 
Station evolution and encompasses the 
subsequent growth or upgrade of Station 
systems and available resources. 


• The Manned Base: This comprises all the partner- 
supplied manned elements of the Program 
composed of the core laboratory and habitation 
modules and their supporting structures (nodes, 
truss, and STS docking facilities). 

• Station Platforms: These comprise the unmanned 
elements of the Program, and include one platform 
that co-orbits with the manned base (Co-Orbiting 
Platform - COP) supplied by the U.S.; and two 
platforms in polar orbit (Polar Orbiting Platforms - 



POP); one to be supplied by NASA and the other by 
ESA. Together the manned base and platforms 
form the operational space components of the 
Program. 

• Station Users: This term is global in scope 
encompassing all varieties of potential users of the 
various Station elements. The SSOTF assumed 
that user operations would be carefully coordinated 
and integrated into overall Station operations, and 
supported by all levels of the Program. However, 
the majority of user activities (such as payload 
selection, definition, development and, in some 
cases, payload-to-rack or PIA integration) would not 
fall under the direct management of the Space 
Station operations organization but would be 
conducted by the users themselves. 

• Space Operations: This term includes all the 
operational components of the Program which 
provide the planning, training, and operational 
management for the conduct of on-orbit activities, 
up to and including the interfaces with the users. 
On-orbit vehicle systems operations, network data 
systems, and supporting ground operations are 
included here. 

• Ground Operations: This term includes all 
components of the Program which provide the 
planning, engineering, and operational 
management for the conduct of integrated logistics 
support, up to and including the interfaces with the 
users. Logistics, sustaining engineering, pre/post- 
flight processing, and transportation services 
operations are included here. 

• Increment Operations: An increment is defined 
as the period of time between STS visits to the 
manned base or between STS (or Station-based) 
OMV servicing visits to a platform. For platforms, 
the term increment may also be used to describe the 
platform’s mission duration or, if a single mission 
platform, its operational lifetime. 

A specific increment’s planning operation may 
begin several years before the relevant STS launch 
(or OMV deployment from the manned base). A 
specific increment’s execution operations begin with 
the Station Program’s real-time support to launch of 
the relevant transportation mission (STS/OMV), 
and generally extends through the initiation of 
similar support to the respective follow-on 
transportation mission. ELV arrivals at Station 
elements are contained within the relevant 
increment. 


For the manned base, increment duration may vary 
according to the number of STS visits per year (for 
eight flights per year, increment duration is 45 
days; for five flights per year, 72 days). For 
platforms, increment duration is related to the 
period between servicing, between deployment and 
return to earth, or between deployment and the end 
of its operational lifetime. 

• Transfer Operations: These are activities related 
to preparing for and conducting resupply, 
maintenance and servicing visits to the manned 


base and platforms. Transfer operations are a 
normal part of the increment planning and 
execution process. Transfer operations encompass 
preparing for arrival of an STS at the manned base, 
or an STS, ELV or OMV at a platform (new or 
previously deployed), and the subsequent ’’transfer” 
of crew and/or equipment as a part of logistics 
resupply, maintenance or servicing, or initial 
platform deployment. Transfer operations also 
encompass the stowage and return of payload 
equipment, trash and experiment samples/products. 

• Maintenance Activities: The task of keeping 
Station systems and hardware within specified 
performance limits. The term maintenance applies 
specifically to Station systems and structure, not to 
user payloads. Functions such as equipment repair, 
replacement, recalibration and cleaning are typical 
of Station systems maintenance requirements. 
These same functions, when performed on user 
systems, are referred to as servicing. 

• Servicing Activities: The Station task of keeping 
user payloads and hardware in operating condition, 
or returning to operating condition. Functions such 
as equipment repair, replacement, recalibration 
and cleaning are typical of user systems servicing 
requirements. These same functions, when 
performed on Station systems, are referred to as 
maintenance. 

• Organizational Definitions: The SSOTF has 

suggested an organizational structure for 
implementing its proposed framework for 
operations. This has been defined as evolving 
through two stages: transition and mature 

operations. These organizations are defined as 
follows: 

1. Transition Operations Organization: The 
operations organization recommended by the 
SSOTF to be immediately established to support 
the Development Phase of the Program. 
Organizational emphasis will be placed on 
establishing clearly defined responsibilities to 
support development of an overall user 
accommodations and space systems operations 
capability supporting the systems design, 
operations planning, assembly, on-orbit 
verification, and early utilization periods within 
the Development Phase. 

2. Mature Operations Organization: The 

operations organization recommended by the 
SSOTF to be established in time to support the 
preparation and management of the Mature 
Operations Phase (beginning with the 
completion of on-orbit verification of the final 
element of the permanently manned Station). 
Organizational emphasis is placed on 
establishing clearly defined responsibilities for 
performing the routine planning and execution 
functions associated with Station utilization and 
systems operations over the lifetime of the 
Program. Provision is also made to support 
planning and integration of evolutionary Station 
systems and operational upgrades as the 
baselined Station configuration grows. 


IX 



PREFACE: SSOTF MANDATE AND HISTORY 


CHARTER AND GOALS 

The Space Station Operations Task Force (SSOTF) was 
created by the NASA Office of Space Station to ensure 
that operations are given due consideration in Space 
Station planning efforts. Specifically, the SSOTF was 
asked to produce an operations framework which meets 
the Program objectives of safe and user-friendly 
operations, supports participation of Canada, the 
European Space Agency, and Japan in the operation of 
the Station, and gives due consideration to the long 
term issues of systems and user operations costs, 
evolutionary goals, maintaining NASA's technology 
base, and furthering science and development. 

Dr. Peter Lyman of the Jet Propulsion Laboratory and 
Carl Shelley of Johnson Space Center were selected as 
co-chairmen for the SSOTF in September, 1986. The 
co-chairmen recruited staff for the SSOTF from a broad 
spectrum of NASA expertise. Special effort was made 
to solicit membership from both within and outside the 
Office of Space Station to provide a balanced knowledge 
base on how to conduct operations. All Field Centers 
and NASA Code organizations were represented, and 
the program experience of the combined membership 
drew from NASA's entire program history. (See Table 
i-1.) 

The charter of the SSOTF included the determination 
of functional operations requirements for the program; 
evaluating alternatives for satisfying identified 
requirements; and development of a Recommended 
Framework for Program operations. 1 The SSOTF was 
asked to identify roles and missions for NASA and its 
partners and to define Program and user interfaces. It 
was also asked to consider the Phase B design concepts, 
and to recommend any changes which would enhance 
operations and utilization. 2 Finally, the SSOTF was 
asked to provide sufficient detail for subsequent in- 
depth cost analysis exercises, and to incorporate 
preliminary assessments of operations costs in 
framework "tradeoff studies." 3 

The SSOTF charter did not cover a range of policy-level 
issues which also could impact Station operations. 
Such issues included providing a Program rationale (or 
"mission statement") for the Station, defining a 
prescribed evolutionary path (i.e., deciding along what 
functional lines the Station should evolve), or 
developing detailed cost estimates for the 
Recommended Framework. Other issues which 
extended beyond the SSOTF charter included assessing 
the adequacy of the STS support capability to 
implement Station operations, and providing a plan to 


accommodate the unique requirements of secure DOD 
operations. These issues need further definition by the 
Program in order to clarify their potential impact on 
overall Station operations. 


METHODOLOGY AND PRODUCTS 

The Task Force began with an extensive series of 
briefings from space systems developers, operators, 
managers and users. The Space Station Program 
Office and Phase B Contractors furnished the Task 
Force with an in-depth review of current Program 
status with regard to both design and operations. The 
Task Force also met with managers and contractors 
from past and present NASA programs, as well as 
Associate Administrators and Center Directors who 
provided the Task Force with the benefit of their 
operations and contracting experience. In addition, the 
Task Force was briefed by a wide range of potential 
users, including a full spectrum from outside NASA 
(academic, commercial, and other government 
agencies). 

The SSOTF methodology is depicted in Figure i-1. The 
SSOTF used the background briefings and materials as 
a baseline for defining a set of operations functions and 
evaluation criteria. Operations functions comprise the 
set of requirements which any Space Station operations 
framework must perform to meet Program objectives. 
Functions were broken down into smaller 
"subfunctions" until end-to-end functional flows could 
be described. The evaluation criteria were developed 
and used as a means of selecting among possible 
framework options and for relating operations concepts 
to achievement of Program goals. 

The Task Force was composed of four panels which 
were divided along functional lines. (See Figure i-2.) 
Within each panel, concepts were proposed, refined, 
and evaluated in terms of their ability to meet 
functional requirements and overall Program goals. 
The four panels were: (1) Space Operations and Support 
Systems; (2) Ground Operations and Support Systems; 
(3) User Development and Integration; and (4) 
Management Integration. Space Operations 
incorporated all operational components of the 
Program which provide the planning, training, and 
operational management for the conduct of on-orbit 
activities. Ground Operations encompassed all 
components of the Program which provide the 
planning, engineering and operational management 
for the conduct of integrated logistics support. User 
Development encompassed all areas of the Program 


'The SSOTF was directed to focus on the mature operations phase of the Space Station , but to ensure that the recommended framework 
accommodates special requirements generated during the development phase through mature operations , and later on to support 
evolutionary growth activities. 

2 ln addition , the Task Force was directed to provide the Office of Space Station with a written response to the Phase C draft RFPs, to 
ensure that SSOTF concerns were incorporated into them to the fullest degree possible. 

3 SSOTF comments were incorporated in the Cost Commitment Team presentation to the NASA Deputy Administrator. One of the 
SSOTF 's major recommendations is the development of detailed cost estimates for the Recommended Framework by the responsible Field 
Centers. 
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Figure i-2 SSOTF Organization 


related to user accommodation and integration 
activities. Management Integration included all 
SSOTF internal concept integration and analysis 
coordination required to provide an integrated 
operations framework. 

After the panels had selected recommended options, 
the Task Force integrated them into a Recommended 
Framework which addressed the entire Space Station 
operations environment. The Recommended 
Framework was used to develop a prototype 
organization for managing the Program. Roles and 
responsibilities were developed and assigned to users, 
international partners, and NASA Headquarters and 
Field Center organizations. A "User Integration 
Scenario" was then drafted to ensure that the 
Recommended Framework would support "real-life" 
operations and to test the flexibility of the framework. 

After drafting the Recommended Framework, the 
SSOTF compared its internally generated baseline 
against the current Space Station Program design and 
operations concepts. Where shortfalls were identified, 
the SSOTF recommended changes to the baseline or 
identified areas where further study is warranted. 

This Summary Report, and associated Executive 
Summary, are the final integrated output of the 
SSOTF. (Detailed User Integration Flows for the 
Manned Base and Platforms are presented as 
supplements to the Summary Report.) In addition, 
each of the four panels has produced an in-depth report 
on its specific area of analysis. 


TASK FORCE SCHEDULE 

In September and October 1986, the Task Force defined 
its tasks and allocated them among the four panels. 
From October through February, the panels developed 
their framework options and conducted preliminary 
evaluations. During March and April, each panel 
presented its findings to the Task Force, and revised its 
report drafts to incorporate changes and utilize a 
common lexicon. A 'Tanel 0", comprised of the SSOTF 
co-chairmen and the panel chairmen met during March 
and April to integrate the panel efforts into the 
Recommended Framework. In a parallel effort, the 
panels worked through the User Integration Scenario. 

Briefings to outside parties occurred at several points, 
(See Figure i-3.) Representatives from ESA, Canada 
and Japan were briefed in November-December 1986, 
and again in mid-February. Partner representatives 
also had access to SSOTF draft papers and materials 
throughout the effort. A final presentation to the 
Partners was made on April 22, 1987. 

The Task Force briefed the SSOTF Oversight 
Committee four times, and received additional 
guidance for options development and evaluation. 
Interim briefings were given in November and 
December 1986, and January 1987; a final briefing was 
given in April 1987. Associate Administrator for Space 
Station Andrew Stofan was given a final briefing in 
late April. The co-chairmen briefed NASA 
Administrator James Fletcher on May 15, 1987. 
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Figure i-3 SSOTF Schedule 


Throughout the effort, informal briefings were held at 
the NASA Headquarters Office of Space Station, the 
NASA Field Centers, the various NASA "user codes” 
(i.e., Office of Aeronautics and Space Technology, 
Office of Commercial Programs and Office of Space 
Science and Applications), and with the Office of Space 


Flight. The Task Force framework was also reviewed 
by the Office of Safety, Reliability Maintainability and 
Quality Assurance in April. These formal and 
informal briefings were used as sources of critique and 
advice, but did not constrain the Task Force's 
recommendations. 
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L SUMMARY OF THE 
SSOTF OPERATIONS FRAMEWORK 


LA. OVERVIEW 

The SSOTF was chartered to produce an operations 
framework for the Space Station Program consisting of: 
(1) a definition of operations functions; (2) the develop- 
ment of an end-to-end planning and execution process; 
and (3) definition of roles and responsibilities for the 
proposed NASA operations organization during both 
the Development and Mature Operations Phases of the 
Program. 

The SSOTF Framework is designed to ensure 
manageable and safe operations that promote the basic 
goal of productive and flexible operations for the 
Station’s user community. Likewise, the Framework 
provides for top-to-bottom participation in the 
operations organization by NASA’s international 
partners (Canada, the European Space Agency, and 
Japan). The Framework is flexible enough to facilitate 
evolution in the Program, both in terms of its physical 
configuration and in its usage. Operations cost consid- 
erations were incorporated; however, achievement of 
the Program's utilization goals was the driving factor 
in defining the Framework. 

The SSOTF recommends separate, though similar, 
operations frameworks for the manned base and 
platforms. The primary feature of the manned base 
framework is a centralized operations planning and 
integration capability. For international activities, 
this means that operations and utilization planning 
are managed by NASA across the Program, with 
international personnel working in the NASA-led 
operations management organization. The interna- 
tional partners will support their contributions 
through the provision of user accommodation and 
engineering analysis facilities at partner sites. 

User planning activities are led by the user 
community. U.S. user planning can be conducted on a 
geographic or disciplinary basis. User requirements 
are collated on a national basis by Space Station User 
Boards and "fused" at the Program Policy (Strategic 
Planning) level by a Multilateral Control Board 
chaired by NASA and staffed by NASA and its 
partners. At more detailed levels of planning, user 
activities are conducted by user working groups and 
supported by Station accommodation offices, while at 
the real-time operations level user activities are 
coordinated by a payload operations integration orga- 
nization. 

On orbit, an integrated international crew performs on 
a functional/skill basis, rather than as "element 
experts." The crew will be composed of both career 
(SSP) and non-career astronauts. On the ground, real- 
time operations of space systems are centralized within 
a single control facility. User operations integration 


activities (as opposed to user operations) for the current 
increment are also performed by a single facility. 
Logistics operations support personnel will perform 
integrated logistics support and prelaunch/postlanding 
processing of flight hardware at dedicated launch site 
facilities. Station users may integrate their payloads 
into internal flight racks or onto external truss 
adapters at distributed Science and Technology centers 
prior to delivery to the launch site for final acceptance 
and launch. 

The SSOTF recommends that the unmanned platforms 
be operated by the contributing partner and separate 
from the manned base to provide maximum flexibility 
in user operations. Strategic utilization planning will 
be coordinated with the manned base, but tactical and 
execution level activities will be largely independent, 
except for the servicing and maintenance of co-orbiting 
platforms at the manned base. Platform operations 
will be managed in a manner similar to current 
unmanned satellite programs, with extensive support 
for user telescience operations. 

I.B. OPERATIONS FUNCTIONS 

An operations function is a task or set of tasks required 
to sustain space operations. 1 The Task Force consensus 
was that the Space Station Program did not involve 
any completely new operations functions other than 
regularly scheduled resupply and changeout of user 
payloads. While Space Station is complex (both in 
"quantitative" terms relating to its size, and "quali- 
tative" terms relating to its multiple uses), previous 
NASA missions have already mapped out similar 
operations functions. What is different is how NASA 
and its partners must organize to perform those 
functions, and the greater degree of flexibility which 
the operations framework must incorporate to meet its 
diverse and changing day-to-day tasks. Likewise, the 
Program’s operations framework must embody a life 
cycle cost orientation consistent with its long mission. 

Space Station operations functions can be defined in 
terms of categories of activity (related subfunctions). 
These categories are presented in Figure 1-1. They fall 
naturally into three areas: Operations Oversight, 
Program Operations and User Operations. The Safety, 
Reliability Maintainability and Quality Assurance 
(SRM&QA) function is interwoven in both user and 
systems operations. 

Operations Oversight 

NASA and its partners will need to establish, monitor 
and revise overall Program policies as required for 
Space Station operations. Many of these activities, 
such as budget planning and program performance and 
cost assessments, will be continuous in nature. Others, 


1 This definition separates activities involved in design, development, test and engineering (DDT&E) from operations. Phase C 
development efforts are not operations functions. However, the dividing line between DDT&E and operations can be very fine. For example, 
while building an additional module for the manned base would not be an operations function, activities associated with defining the 
requirements for the new module, approving its inclusion in the Program, engineering and operations assessments of the impact of the new 
module on the existing configuration, and manifesting and launch and integration of the new module, would be operations functions. 
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Figure I- 1 Operations Functions 


such as specific international negotiations or evolution 
planning will be "requirement-driven" and occur on a 
less frequent basis. These functions apply to the broad 
conduct of both user and SSP operations, and hence 
serve as the strategic frame within which all activities 
occur. 


User Operations 

User Operations are those activities which are 
conducted by the user community. These can be broken 
into four subcategories: Resource Allocation; User 
Selection; Payload Development and Integration; and 
Payload Operations. These categories have a temporal 
relationship for an individual user: from the announce- 
ment of a flight opportunity to the performance of an 
experiment. From the Program perspective, all of the 
functions will be performed concurrently, as multiple 
users "work their way through the system." 


Program Operations 

Space Station Program Operations are those activities 
which the SSP must perform to ensure that the Station 
elements are operated and maintained in a safe 
manner, and to support utilization of the Station 
resources by users. These fall into four subcategories: 
Utilization and Operations Planning; User Integra- 
tion; System Operations and User Operations Support; 
and Systems Engineering and Integration. 2 


I.C. OPERATIONS CONTROL AND PLANNING 
HIERARCHY 

The SSOTF further detailed the operations functions 
presented in Figure 1-1, and then hierarchically 
grouped the resultant subfunctions into three basic 
levels of management and control: Program Policy 
("strategic"), Program Integration ("tactical") and 
Program Execution (real-time operations). 3 This man- 
agement hierarchy exercises control over four levels of 
planning, each of which has one or more major plan- 
ning products associated with it. The four planning 
levels are: Strategic Utilization and Operations Plan- 
ning (five-year planning horizon); Tactical Utilization 
and Operations Planning (two-year planning horizon); 
Increment Planning (development of detailed planning 
and scheduling data for an increment specific time 
frame); and Increment Execute Planning (development 
of execute level plans and procedures to perform 
increment operations in real-time). The Program Inte- 
gration (tactical) level of management controls both 
the Tactical Utilization and Operations Planning and 
Increment Planning functions. This hierarchy, and the 
major planning products associated with each manage- 
ment level are presented in Figure 1-2. 

Strategic Utilization and Operations Planning 

At the strategic level (defined as a planning horizon of 
five years), utilization planning is performed by each 
partner in accordance with allocations of resources as 
defined by international Memoranda of Understanding 
(MOUs). In the U.S., this will be done by a Space 


s Detailed descriptions of these functions are presented in Section III. A. 

3 Many times, a single function (such as utilization and operations planning), will extend through all levels of management, while other 
functions (such as systems operations and user operations support) are generally associated with a single management level (Program 
Execution in this case). Hence, many functions will be performed simultaneously at multiple levels of management , and in multiple 
organizations within a single level of management. A complete regrouping of operations functions by level of management responsibility is 
presented in Appendix B of this report. 

coto* ^ 
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Figure 1-2 Recommended Framework 
Planning And Control Hierarchy 


Station User Board (SSUB) consisting primarily of 
user-sponsoring organizations. 4 Partner SSUB plans 
are brought together and reconciled by the internation- 
ally staffed strategic level boards provided by the 
MOUs. 5 Technical support is provided by the Program 
Policy level staff, or the Program Integration level 
utilization/operations organization. The yearly output 
of these boards is a Consolidated Utilization Plan 
(CUP) which contains the Program's "rough cut" pro- 
jection of resource requirements for Station operations 
and user activities. 

Tactical Utilization and Operations Planning 

The CUP is passed to the tactical level utilization and 
operations organization. A Program Operations 
Control Board oversees the development of a two-year 
Tactical Operations Plan (TOP), which manifests users 
to specific flight increments. The internationally 
staffed Program Operations Control Board is located in 
the NASA Headquarters Program Office and enlists 
the support of the NASA field centers and partners in 
this function. At the head of this organization is the 


Director of Utilization and Operations. Figure 1-3 
illustrates the hierarchy of control functions at each 
management level. 

In addition to manifesting user payloads on the 
manned base, the TOP also manifests system mainte- 
nance and resource requirements and contains logistics 
and STS/ELV/OMV transportation plans. TOP prepa- 
ration is a continuous process during which changes to 
individual flight increments are negotiated and 
incorporated. (See following discussion on increment 
planning.) 

A Space Station Users Working Group (SSUWG), 
consisting primarily of the users (or their discipline 
representatives) contained in the CUP will support the 
development of the TOP. A key feature of the 
Recommended Framework is the strong role played by 
users in operations planning. In addition, a Program- 
sponsored Payload Accommodation Manager (PAM) is 
assigned to each payload that appears in the CUP. The 
PAM provides the single point of contact for an individ- 
ual user to the Station Program. The PAM stays with 


4 These include the NASA Offices of Space Science and Applications, Commercial Programs, Aeronautics and Space Technology, and 
Space Station (representing commercial reimbursable users), as well as representatives from other governmental agencies . 

5 Multilateral Control Board, User Operations Panel', and Systems Operations Panel. 
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Figure 1-3 Program Control Summary 


the payload through its life-cycle with the Program, 
including design and development, manifesting, 
transport to orbit, operation and return. One PAM is 
expected to be able to work with several payloads at a 
time. Figure 1-4 illustrates the flow of the strategic 
and tactical level planning functions. 

Increment Planning 

The TOP becomes the basis for the generation of Flight 
Increment Plans (FIPs), covering the period of time 
between STS visits to the manned base. STS visits 
represent an opportunity for crew and equipment 
configuration change, and hence are the appropriate 
Operations Execution level planning milestones. 
Increment lengths will vary according to the number of 
STS visits per year. 6 

Increment planning is also a Program Integration level 
function, with greater involvement of Program 
Execution level offices for provision of the necessary 
technical support. Planning for user activities 
associated with each increment is developed by a 
Payload Operations Integration Center (POIC), with 


guidance from the users’ Investigators Working Group 
(IWG) and within Space Station Support Center (SSSC) 
guidelines. 

For manned base operations, Increment Change 
Managers 7 are assigned the authority and responsibil- 
ity to manage the integration of Program and user 
operations requirements, plans and schedules for a 
specific increment. Typical senior management 
responsibilities of the Increment Change Manager will 
include: direct and expedite specific plans for the 
accommodation of manifested user requirements; 
integrate transportation and data system organization 
needs and capabilities into the manned base planning 
process; identify any increment-unique requirements 
for Program and user logistics and prelaunch/post- 
landing processing support; and identify the specific 
ground operator and onboard crew skills required to 
support increment objectives. 


The NASA Headquarters SSP organization will 
maintain control over and be responsible for tactical 
and increment utilization and operations planning. In 


6 Assuming eight STS visits per year, increments are 45 days in length , and a TOP covers 16 increments. With five STS visits per year, 
increments are approximately 72 days long, with ten increments covered in a TOP. 

7 The term ’Change" in the title reflects the fact that this manager will he responsible for coordinating those requirements which are new 
to an increment , as opposed to activities which carry-over from previous increments. It is expected that a substantial portion of manned base 
activity will be of the latter kind. 
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Figure 1-4 Strategic And Tactical Planning Process Flow 


practice, it is expected that many of the technical 
analysis and support tasks will be delegated to the 
various field centers. 

Increment Execute Planning 

Increment Execute Planning entails preflight 
development of detailed operations and utilization 
execution plans and related data, as well as the real- 
time replanning of operations in response to contin- 
gencies or new opportunities. Execution plans and 
related data are derived from the relevant FEP. Such 
plans include the Increment Operations Plan (IOP), 
Flight Data File (FDF), Increment Hazard Control 
Plan (IHCP), Flight Rules, Reconfiguration Data and 
other real-time execution plans and supporting 
documentation as called for in the FIP. Figure 1-5 
illustrates the flow of the increment planning and 
increment execute planning process. 

I.D. OPERATIONS EXECUTION 

Operations execution includes the detailed functions 
associated with implementing flight increment 
schedules for prelaunch scheduling and processing, 
launch and transfer operations, on-orbit activity 
(including ground support), and return and postlanding 
activity. NASA field centers, international partner 


and user operations facilities will execute the plans and 
procedures derived from the Increment Execute 
Planning function. Location of operations activities 
and key functional characteristics are: 

Space Station Support Center (SSSC): The SSSC is 
a Program-provided facility which centralizes systems 
management and control for the manned base, 
including the elements provided by the partners. Crew 
and manned base safety are SSSC responsibilities as 
well. A key role of the SSSC is to provide a ’’template" 
of systems management responsibilities and resource 
requirements which are used to schedule payload 
activity windows. 8 The SSSC also approves the 
resulting schedule of user and systems activities. Crew 
training facilities are closely associated with the SSSC 
(and POIC). International partners will support the 
conduct of operations for their elements by providing 
responsible flight control staff at the SSSC, as well as 
providing real-time engineering support from facilities 
located in their own countries. 

Payload Operations Integration Center (POIC): 
The POIC is a Program-supplied facility whose 
function is to schedule user activities for the manned 
base, building on the template provided by the SSSC. 
It integrates the user requirements according to user 
resource envelopes and available resources provided by 


a The SSSC template will allow for sliding schedules for noncritical systems activities to provide for time -critical payload activities. 
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Figure 1-5 Increment And Increment Execute Planning Process Flow 


the SSSC, assists users in periodic "replanning," aids 
the IWG in user conflict resolution, and supports 
distributed user facilities in real-time or near real-time 
execution activities. Thus, on-orbit crew time and 
other resources available for users are managed by the 
POIC in cooperation with the SSSC. The SSSC will 
normally be transparent to the user community during 
routine payload operations. 

User Operations Facilities: A variety of user- 
supplied and operated facilities are envisioned to meet 
specific needs of the users. They can be equipped to 
support the range of user operations involved in 
payload management (i.e., command, control and 
communications for experiments, data analysis and 
storage, etc.). These facilities shall be established 
according to user preference. However, the SSOTF 
foresees three basic approaches: (1) Discipline Opera- 
tions Centers (DOCs); (2) regional operations facilities; 
and (3) stand-alone or proprietary User Operations 
Facilities (UOFs) maintained by a single user or group 
of users. (See Figure 1-6.) 

DOCs are user-supplied and operated facilities which 
provide support to a discipline user group which is 
centered around a specific area of investigation. They 
are intended to allow for the sharing of technical 
support and overhead costs to users with similar 
discipline needs. The DOCs will interface with the 
POIC for coordination of their payload planning 


activity, and may be affiliated with a regional 
operations facility as well. They may also be affiliated 
with a number of independent UOFs. Examples of 
discipline categories include: materials science, life 
science, technology development, earth observation, 
etc. 

Regional operations facilities incorporate both 
Regional Operations Centers (ROCs) and affiliated 
DOCs. The ROCs are user (or partner) supplied and 
operated facilities which are geographically focused to 
provide support to regionally based user groups. The 
intention is to share common overhead costs or 
technical interests with regionally grouped users. A 
ROC will include facilities to support user operations 
integration functions and coordinate disparate user 
activities during flight preparation and execution. 
ROCs will interface with the POIC for support in 
scheduling and real-time replanning activities. ROCs 
may be affiliated with different DOCs or a number of 
independent UOFs within a regional operations 
structure. 

Stand alone or proprietary UOFs may be physically co- 
located at NASA or partner sites or at user-selected 
industrial, research or academic sites. Each may be 
affiliated with a DOC or ROC or may report directly to 
the POIC for integration of plans and requirements 
with those of other users. 
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Figure 1-6 Manned Base Operations Framework 
Real-Time Operations -- Systems And User Support 


Platform Support Center (PSC): The SSSC and 
POIC functions are combined for platform operations in 
a PSC. It is likely that two will exist; one for the U.S. 
polar and co-orbiting platforms, and one in Europe for 
the ESA polar orbiting platform. 

Space Station Processing Facility (SSPF): The 
SSPF will house the prelaunch processing activity for 
all Space Station hardware to be transported to orbit 
via the STS. (Similar facilities will exist at other 
launch sites.) In the Mature Operations Phase, the 
logistics flight hardware will undergo prelaunch and 
postlanding processing ("turnaround"). The partners* 
flight hardware may be processed in this facility as 
well, with element-unique activity the responsibility of 
the providing partner, and integration activity led by 
NASA with partner participation. The SSPF will 
perform all interface and safety verification testing for 
the Program before delivering payloads and carriers to 
the transportation operations organization for STS or 
ELV integration. 

Payload integration will be performed in a modified 
’’ship and shoot*' mode. Users may build and/or 
integrate racks and experiments at "Science and 
Technology Centers" certified by the Program. These 
centers will be located at NASA field centers, partner 
facilities, or user facilities, and are likely to evolve 


from existing institutional payload development 
capabilities. As an optional service, launch sites will 
also have a capability to build up and/or integrate 
payloads for users. All payloads and orbital 
replacement units (ORUs) will undergo final interface 
testing at the launch site. 


Logistics Operations Center (LOC): Program-wide 
logistics support operations are centrally located and 
managed. Key aspects of LOC functions include 
management of logistics information and data bases, 
inventories (ground and onboard), configuration, 
transportation systems interface, packaging, handling 
and ground transportation. The LOC will support a 
line item population on the order of 300,000, including 
2,500 orbital replacement units (ORUs). A key feature 
of the LOC is its extensive use of automated test 
equipment for in-house maintenance and repair. 

Engineering Support Centers (ESCs): Located at 
the NASA and partners' hardware development 
centers and the launch site(s), these facilities will 
provide engineering and real time consultation support 
on an on-call basis. They also will perform sustaining 
engineering in the Development and early Mature 
Operations Phases. The SSOTF Framework calls for 
development of a transition plan which would 
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eventually centralize sustaining engineering for U.S. 
orbital elements. Sustaining engineering for ground 
support systems and information systems would 
remain distributed to the U.S. operations centers and 
the partners' sites. 

I.E. ROLES AND RESPONSIBILITIES 

Figure 1-7 provides a summary overview of the entire 
flow from strategic through execution operations. As 
noted above, the Framework recommends a centralized 
planning and management function led by NASA with 
the participation of the international partners at all 
levels. The following operations roles are recom- 
mended to be assigned to the following field centers and 
international partners for the Mature Operations 
Phase: 

Program policy and integration functions are 
performed at NASA Headquarters. The SSOTF 
assigned these functions to Headquarters for many 
reasons. These include the ability to provide a single 
interface for issues affecting the international 
partners; the necessity to manage and integrate the 
operations of multiple operations centers; the need to 
establish close coordination at senior management 
levels between the Space Station, space transportation, 
communications and data services utilization and 
operations planning organizations; the need to 
integrate long term planning for operations with the 
budget development process; and the need to 


strengthen Program management. NASA leadership 
in these functions is predicated upon NASA’s larger 
resource contribution to program development and 
operations, and on NASA’s significantly greater 
experience in manned space flight operations. 

Integrated logistics and prelaunch/postlanding 
processing functions are located at Kennedy Space 
Center in the LOC and SSPF, respectively. This 
assignment takes advantage of KSC’s depth of 
experience in NASA manned programs (including 
prelaunch and postlanding processing, logistics and 
transportation services). It also offers the opportunity 
for synergistic benefits by coordinating with the 
logistics support and payload processing and 
integration activities already performed by the STS 
organization at KSC. This assignment includes the 
integration of space systems ORU maintenance 
requirements as received from the various engineering 
support centers and their delivery to the SSSC for 
planning and execution. 

Manned base systems operations and 
maintenance implementation responsibility is 
assigned to the Johnson Space Center and its SSSC* 
This will allow the Program to efficiently utilize JSC’s 
expertise as the lead manned space flight operations 
center. It also offers the opportunity for synergistic 
benefits by coordinating STS operations activities, 
facilities, crew support and training with the SSP's 
counterparts. 



Figure 1-7 Summary: Manned Base Operations Framework 
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Manned base user operations integration is 
delegated to the Marshall Space Flight Center and its 
POIC. This includes the integration of user 
requirements for ground and onboard payload 
operations and servicing. MSFC is the development 
center for the U.S. laboratory module and will have 
developed the detailed "corporate knowledge" of this 
user-oriented element. MSFC also has existing 
expertise through its role in the Spacelab Program and 
its associated Payload Operations Control Center. 
Finally, the SSOTF felt that assignment of user 
operations integration activities to MSFC would 
establish a stronger "user-directed" activity than 
would be the case if it were co-located with system 
operations activities. 

U.S. platform operations are assigned to the 
Goddard Space Flight Center and its PSC. GSFC's 
development role for the platforms, its expertise in past 
unmanned systems operations, its experience in 
supporting the platform science and application user 
community, opportunities for synergy with existing 
platform facilities, and the Task Force's conclusion 
that platform and manned base operations should be 
separately operated all led to this decision. 


ESA platform operations are assigned to the 
European Space Agency and its PSC for the same 
reasons that the U.S. platforms are assigned to GSFC. 
In addition, it was noted that ESA plans to develop a 
European Data Relay Satellite (EDRS) and associated 
ground systems would undoubtedly require close 
cooperation between the ESA platform operator and 
the EDRS development organization. 


Engineering support is initially distributed to ESCs 
staffed by the NASA field center and international 
partner organizations responsible for the development 
of the major Station elements (MSFC, JSC, GSFC, 
LeRC, KSC, ESA, Japan, Canada). It was judged that 
this would facilitate a smooth transition from 
development engineering to sustaining engineering as 
the various Station systems are assembled and mature 
into full operational status. Once the fully integrated 
Station is demonstrated to be operationally mature 
(systems are stable and reliable and their performance 
characteristics predictable), consideration will be given 
to centralizing the sustaining engineering function for 
U.S. orbiting elements at KSC. 



II. SPACE STATION PROGRAM OVERVIEW 


The Space Station Program will be the keystone of 
NASA's space efforts for the next three decades. The 
Program will offer a dynamic resource base for 
conducting both manned and unmanned science in 
space, as well as providing an expanded capability to 
conduct "traditional" space science and applications. It 
will also support a variety of new space operations such 
as commercial research and pilot production activities 
utilizing the unique properties of the space environ- 
ment. Part laboratory, part observatory, part servicing 
and repair facility, the Space Station will greatly 
expand America's existing space capabilities. With a 
Program lifetime of up to 30 years, operating the Space 
Station will place new and challenging demands on 
NASA and the participating international partners. 

II. A. SPACE STATION PROGRAM GOALS 

Given the size and importance of the Space Station to 
the civilian space program, it is not surprising that its 
mission goals are extensive. The SSOTF endeavored to 
construct its operations framework to support the 
overall goals of the Program. The following goals were 
compiled by the SSOTF from published Program 
documentation, and fall within four broad categories: 
(1) encourage scientific and technological development 
and discovery in utilizing the space environment; (2) 
leverage such discoveries into tangible, long-term 
national economic benefit; (3) improve space operations 
by improving effectiveness and reducing costs; and (4) 
support the foreign policy goals of the United States by 
promoting international cooperation in the peaceful 
uses of outer space. These goals are summarized in 
Table II- 1. 
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II.A.L Scientific Technological Development and 
Discovery 

The primary goal of the Space Station Program is to 
provide user-oriented capabilities which fulfill the 
NASA mandate for discovery, exploration, and 
utilization of the space environment. The Space 
Station's closest historical analogies for manned 
spaceflight are the Skylab and Spacelab programs, 
which were developed as general purpose support 
facilities for science and technology development. The 
Space Station's platforms are analogous to previous 
unmanned scientific satellites and will be operated 
much the same as past and present "free flyer" 
programs. In contrast with its predecessors, however, 
the Station Program embodies considerably broader 
objectives. The Station must serve a wider range of 
"customers" for a much longer period of time. 


A second aspect of this goal is to advance America’s 
space technology base through development of new 
technologies utilizing the Station's hardware and 
software capabilities. In this fashion, the Space Station 
can provide facilities for the testing of advanced 
systems which are necessary for future projects such as 
a permanent manned presence on the moon or a 
manned mission to Mars. Like the user-support goal, 
this objective is quite broad in scope, covering all of the 
technological disciplines that are embodied in space 
systems. 



Table 11*1 Space Station Program Goals 
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II.A.2. National Economic Return 

NASA’s technology base has been, and continues to be, 
a valuable industrial asset to the nation’s economy. 
While early NASA programs were not specifically 
designed to generate ’’spinoffs” to industry at large, 
experience shows that NASA's development of new 
technical capabilities has led to breakthrough 
technologies of interest to industry and accelerated 
technology development in many areas. These direct 
spinoffs to the aerospace and computer industries have 
enhanced their productivity and international competi- 
tiveness. 

A second aspect of this goal is to support the 
development of commercial space initiatives. The 
public investment in the NASA program is analogous 
to earlier support by the government in the infra- 
structure of commerce. Waterways, railways, aviation 
and the interstate highway system are all examples of 
public sector investments which were undertaken to 
stimulate economic enterprise. Early investments in 
space transportation systems and satellite technology 
precipitated the commercial communications satellite 
industry; likewise, the presence of permanent 
laboratory facilities in space should serve as a catalyst 
for innovative commercial research and development, 
and the commercial provision of space products and 
services. 

The third aspect of this goal is the stimulation of 
technologies of benefit to U.S. industry as a whole (as 
opposed to aerospace applications alone). As noted 
above, the space programs of the 1960s paced many of 
the advances in computer technology. The U.S. 
Congress has become especially interested in the 
industrial benefits of investment in the Space Station, 
and has specifically directed NASA to highlight 
advanced automation and robotics technologies. Other 
technologies of interest to Station operations include 
information systems, environmental control and moni- 
toring, solar power generation and storage, and waste 
management. 

II.A.3. Improved Effectiveness of Space 
Operations 

Space is a demanding environment, and these demands 
are reflected in the high cost of space hardware and 
operations. As a result, there has been a concerted 
effort in the U.S. space community to understand the 
factors which drive costs, and to reduce them wherever 
possible. 1 Numerous studies conducted by both NASA 
and the Department of Defense have cited under- 
estimation of operational factors as a major driver of 
costs. This is especially important for the Space 
Station Program, since its operations lifetime is 
projected to span three decades. 

The importance of operations costs forces NASA to 
approach design and operations from a life cycle cost 
perspective. Design must be linked to anticipated 
system and user requirements in the Mature 


Operations Phase so that proper tradeoffs can be made. 
(The least costly design may cost more to operate than 
it saves in development cost.) 


One specific method for reducing the costs of operations 
is to effectively use scarce resources on the manned 
base. Crew time will be one of the most expensive and 
scarce "resources"; power will be another. To make 
optimal use of crew time, operations should influence 
both the design process and the development of 
operations procedures and schedules. This suggests 
design decisions incorporating human factors 
engineering and performing trades between assigning 
tasks to automated systems, crew, or ground support 
personnel. It also suggests designs and operational 
techniques permitting non-critical control, monitoring, 
and maintenance tasks to be performed by automated 
means or by remotely controlled systems. 2 In 
performing these analyses, the guiding principle 
should be "have men perform tasks which require 
man's presence." Other criteria which must be 
considered are safety, the availability of technology, 
and costs. 


A second method is to develop common and easily 
maintained hardware and software whenever possible. 
Emphasis for space hardware, software, and data 
system interfaces should include such factors as 
common standards, the development of common 
"orbital replacement units" (ORUs) across hardware 
elements, and the inclusion of fault isolation, self-test 
systems, accessibility and ease of handling/replace- 
ment in systems design. Modularity, common 
interfaces, and "oversizing" (i.e., providing over- 
capacity) of such elements as data management system 
components are essential if systems are to be easily 
upgraded over time. The Program should also strive to 
develop common safety and payload integration 
requirements for Space Station, taking into account the 
STS so that users do not have to respond to varying 
requirements. Likewise, logistics and space operations 
support to both programs should derive benefits from 
developing common standards, procedures, and 
equipment. 


A third method is to design and operate the manned 
base as an "organic facility" which can evolve to meet 
changing user requirements and to take advantage of 
new capabilities as they become available. To achieve 
this goal and allow for minimum intrusion in on-going 
activities when new capabilities are added, the initial 
systems should be designed for technology trans- 
parency (i.e., allowing for minimum disruption by 
making the addition of new technologies as simple as 
possible). Once again, this goal reinforces the goal of 
industrial spinoffs, as many of the anticipated 
advances in Space Station technology would be of 
interest to industry at large. 


* Another way of looking at this goal is to consider it from the productivity standpoint: to increase the amount of "return " per unit of cost. 

2 These Program goals are often reinforcing. For example, development of advanced robotics capabilities not only maintains U.S. 
technological pre-eminence , but could also reduce the cost of space operations, and will likely provide a source of innovative concepts for 
earth-based industry. 
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Figure II- 1 Space Station Program Elements 


which will "crawl” over the trusswork to perform these 
tasks. The robotic arm will be supplied by Canada; 
NASA will sponsor development of the mobile base. 
The MSC will also have a set of controls attached to its 
base which will allow astronauts to use it during EVA. 

The U.S. will supply an unpressurized servicing 
facility which will be attached to the truss. It will 
enable astronauts to berth, store, assemble, repair, 
refuel, refurbish and test free-flyers and attached 
payloads. The facility will contain an in-bay manipu- 
lator system with effectors (hands) that is teleoperated 
from a control station. 7 

The manned base will have a number of additional 
hardware elements which increase crew capability. 
Another robotics device known as the Flight Tele- 
robotics System (FTS) will attach to the Orbital 
Maneuvering Vehicle (OMV). 8 The FTS/ OMV will be 
able to grapple satellites and bring them to and from 
the manned base or Shuttle for servicing. The 
FTS/OMV will also be able to carry modular "orbital 


replacement units" out to the unmanned platforms, 
and carry out on-site servicing of satellites without 
having to bring them back to the manned base. 

Unmanned platforms will support a broad range of 
scientific and technology development activities. 
NASA will provide platforms in polar orbit and the 
same 28.5 degree inclination orbit as the manned base 
(co-orbiting); ESA will provide an additional platform 
in polar orbit. 9 The platforms will be much larger than 
most present-day platforms, and will thus support 
more and larger experiments. Station platforms are 
designed for on-orbit changeout of payloads and 
servicing, as compared with current platforms which 
are "thrown away" when their payload mission is 
completed. 

The Space Station will utilize logistics carriers to 
transport pressurized cargo (e.g., life sciences experi- 
ments), unpressurized cargo (e.g., tools, new instru- 
ments, spare parts, etc.), propellants, and fluids. The 


7 This facility is part of the Phase II configuration. 

8 The first OMV will be Shuttle-based; eventually , a second OMV will be permanently based at the manned base. 

9 Polar orbits are especially well suited to Earth observation missions, since they orbit the entire surface of the globe. Sun- synchronous 
polar orbits allow the satellite to make its passage at the same local time daily on successive passes. A 28.5 degree inclination (the standard 
orbit from a due-east launch from Kennedy Space Center) is good for space observation missions , and for locating payloads that must be 
serviced or "harvested” by the manned base or STS. The NASA co-orbiting platform is now part of the Phase II configuration. 
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II.A.4. International Cooperation 

The NASA space program has always been an effective 
mechanism for promoting U.S. foreign policy. 
Cooperative scientific endeavors provide tangible 
benefits to cooperation in both the short and long 
term. 3 First, both NASA and its partners will benefit 
from the pooling of resources: users will have a facility 
with much greater capability than if each partner had 
developed separate facilities. Thus, the partners are 
expected to make substantial technological contribu- 
tions to the Program. 

Secondly, it is clear that NASA's partners will continue 
to expand their space capabilities. The partners will, 
sooner or later, replicate the functional capabilities 
which NASA has in both manned and unmanned space 
operations. This suggests that: (1) the opportunities 
for cooperation will continue to proliferate; and (2) to 
maximize the potential for continued cooperation, 
NASA and its partners should develop policies, 
procedures, and protocols which are mutually 
beneficial as well as being supportive of specific 
national goals. 

This process recognizes that U.S. and partner goals in 
the Program will not always coincide. (To the extent 
that NASA's partners develop their own technology 
base through the Program, they challenge the market 
position of U.S. industry.) Hence, both the develop- 
ment and operations aspects of the Program will 
require some compromise among these goals. 

II.B. CHARACTERIZING SPACE STATION 
OPERATIONS 

Operations functions and the concepts for supporting 
them are derived from analysis of the Space Station's 
hardware elements and their intended uses. This 
section is a summary of the major aspects of the Space 
Station Program's hardware configuration, and 
provides a "snapshot" of the kinds of activity which will 
occur during operations. 

II.B.l. Space Station Configuration 

The SSOTF was given the reference configuration 
published by NASA’s Critical Evaluation Task Force 


(CETF) in September 1986 as its baseline. This 
configuration defined the Station's hardware elements, 
and the resource capabilities which they provide. 4 

The major space-based elements of the Space Station 
Program are the manned base and unmanned 
platforms. (See Figure 33-1.) The manned base will 
consist of four pressurized modules: two supplied by 
NASA (one for use as a laboratory and one for habita- 
tion); a second laboratory supplied by the European 
Space Agency (ESA); and third supplied by the 
National Space Development Agency of Japan 
(NASDA). 5 The platforms will consist of a co-orbiting 
platform and a polar orbiting platform (COP and POP, 
respectively) supplied by the United States. ESA will 
also supply a polar orbiting platform which will 
operate independently of the U. S. platforms. 

On the manned base, the pressurized modules will 
provide the main living and working quarters for an 
international crew of eight. Four "Resource Nodes" 
will connect the modules, and provide additional 
working space. Current plans call for the manned 
base's control systems to be located in the nodes. While 
the modules will be contributed by different partners, 
they will share a complex network of "distributed 
systems": environmental control and life support 
(ECLS); guidance, navigation and control (GN&C); 
propulsion; power; data management; communications 
and tracking; structures and mechanisms; fluids; and 
thermal management. 


The modules and nodes will be attached to a large truss 
structure supplied by NASA. The truss will also 
support the photovoltaic and solar dynamic power 
systems for the manned base, 6 an unpressurized 
satellite servicing facility (see below), and provide a 
base for mounting payloads which do not require 
continual man-tending or an atmosphere. 

A Canadian-built Mobile Servicing Center (MSC) will 
allow astronauts inside the pressurized modules to 
manipulate exter-nally mounted (or "attached") 
payloads, to bring transportation vehicles in for "soft 
docking", and to perform routine inspection and 
maintenance of the outside of the manned base. The 
MSC has a large robotic arm mounted on a moving base 


3 The SSOTF was directed to assume that the Space Station Program will include international partners in both development and 
operations. It was further directed by the SSOTF Oversight Committee to assume that the U.S. will play the lead role, consistent with its 
dominant financial contribution to the program and its more extensive experience in manned space systems. 

Importantly , there will likely be considerable "cross -utilization" - U.S. researchers working in foreign modules (a substantial portion of 
the resources of the foreign elements will be reserved for U.S. users by international agreement ), and foreign researchers using U.S. 
modules. Such resource sharing will impose significant integration and planning requirements on the Program. 

4 The CETF also proposed an assembly sequence for delivery by the Shuttle of these elements to orbit. The SSOTF used this as the 
baseline for evaluating the transition phase of their operations concepts. The recent decision by NASA to propose a two-phased approach to 
Program development does not materially alter the operations environment for Station activities, but lengthens the time between 
development and final mature operations of the manned base and the platforms. 

s The European Space Agency laboratory module is known as ' Columbus Japan is supplying the Japanese Experiment Module (JEM) 
for use as a lab. The JEM will also include an exposed payload facility for mounting racks of experiments, a robotic arm operated from 
inside the JEM, and a logistics module for storing equipment and payloads used in the JEM. It is expected that as the manned base evolves 
over time, additional modules will be added to the four which are part of the baseline configuration. 

6 Phase I plans call for initial deployment of a 75kw photovoltaic array; solar dynamic power systems will be added in the Phase II 
configuration for a total system power of up to ISOkw. 
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largest of these will be the pressurized logistics 
module, which will attach to a resource node on the 
manned base for shirtsleeve access by the crew. The 
logistics carriers will be ferried to and from the 
manned base and the platforms by the STS and, 
possibly by expendable launch vehicles. 


Integrated throughout all of the hardware elements is 
a Space Station Information System (SSIS) which uses 
existing and planned NASA, partner, and user- 
supplied space and ground communications systems. 
The manned base will have an internal communi- 
cations system which is tied to the ground through the 
NASA Tracking and Data Relay Satellite System 
(TDRSS). Likewise, U.S. platforms will use the TDRSS 
for the relay of data to and from the Platform Support 
Center. A Data Interface Facility at the TDRSS 
ground terminal in New Mexico will serve as a 
"communications node" for distributing user data 
coming down from the Station (via TDRSS) to users at 
geographically dispersed locations. The NASA 


Communications Network (NASCOM) supports the 
transfer of real-time operations data among all of the 
ground control centers. The Program Support Commu- 
nications Network (PSCN) will tie together all of the 
"off-line" data bases and administrative communi- 
cations required to keep the Station functioning 
efficiently (including the Technical Management and 
Information System - *TMIS"). 


This Space Station Program infrastructure will have a 
number of uses over the lifetime of the Program. These 
include: 

• A microgravitv laboratory to conduct experiments 
and technology development activities in the fields 
of life and materials sciences; 

• An observatory to conduct Earth observations 
(climate, earth resources, geodesy, oceanography 
and geology); and for planetary, solar and deep 
space astronomy and physics; 


KEY FEATURES OF THE SSiS ARCHITECTURE 

The Space Station Information System (SSIS) will be an end- to-end data and information system for the Space Station Program and its 
users The SSIS contains a collection of flight and grxxmd elements that are provided by NASA, the international partners, and users 
of the Space Station. As defined in the SSIS Architecture Definition Document, the SSIS supports "the functions of prelaunch 
checkout mission management scheduling and control, software development and the acquisition, transmission, recording, 
processing , accounting, storage, and distribution of data (including audio and video) produced by the Space Station Program, its 
users, and interfacing space and ground elements. a 

From this functional definition it is evident the SSIS is broader than just those systems supporting flight critical activities. As 
interpreted by the Task Force, the SSIS includes real-time networks supporting flight activities and non real-time networks supporting 
Program management. Program development and flight and ground operations activities. The SSIS also provides interfaces to 
separate networks which may be supplied by the international partners or Space Station users. 

The real-time networks include onboard data and communications capabilities (both spacecraft systems and payloads), ground 
control center systems, and the communications links between flight and ground elements. These links are provided by NASA's 
Tracking and Data Relay Satellite System (TDRSS) for space-ground communications and the operational NASA Communications 
Network (NASCOM) for ground da ta transport. The Goddard Space Flight Center manages and controls the TDRSS and NASCOM and 
provides information system services in response to requests generated by the SSSC for the manned base and its users, the PSC for the 
platforms and its users, and the Shuttle Mission Control Center (MCQ for the Space Transportation System, the OMV, and their users. 
The manned base and platforms will require the equivalent of one full-time TDRS link each to support system and payload operations. 
Using these capabilities, the SSIS can support real-time operational communications for data, voice, and video at transmission rates of 
up to 300 mbps. The SSIS also supports the concept of tplescience for support to users. In this mode of operation, SSIS services are 
transparent to the user permitting a direct, real-time communications path between the user's facility and the user's payload onboard 
either the manned base or the platforms. 

Non real-time SSIS elements include the Technical Management Information System (TMIS) and the Software Support Environment 
(SSE). TMIS is an integrated, information system at each of the NASA Centers, the partner sites, and the prime contractors responsible 
for building Program elements. The SSE is a network of distributed Software Production Facilities. The SSE is responsible for 
establishing and maintaining standard tools, rules, procedures, and software development hardware for use in developing, 
maintaining, and upgrading software products. Communications services supporting these elements are provided by NASA's 
Program Support Communications Network (PSCN), an administrative network managed by the Marshall Space Flight Center. 

All of the SSIS elements will have the capability to protect the handling and transmission of proprietary or sensitive data. However, 
the SSIS is not being designed to comply with Department of Defense computer or communications security requirements. 

The SSIS is a complex, global information system. Given the number of interfaces (the SSIS ADD has over SO ground locations 
identified), the different types of interfaces (e.g., data, voice, video), and the different functional uses of the communications links 
(e g., from command and control to routine program planning), there is no simple method of illustrating the network. Figures 11-2 
and 11-3 are top-level charts illustrating the manned base and platform operations infrastructure. The SSIS is used to provide the 
communications connectivity among all of the sites shown in these figures. Readers interested in additional details should consult 
Section IV.I. of this report, the SSIS ADD (JSC Document 30225), and the Space Operations and Support Systems panel report. 

It should be noted that the Task Force SSIS architecture differs from the currently baselined SSIS ADD in terms of functional 
capabilities and locations for various ground- based centers. (See Section IV.I.) These differences will be resolved as the definition of 
the SSIS is refined. It should also be noted that SSIS elements will be provided by different organizations both within and external to 
NASA. Additionally, not all of the capabilities required by SSIS are dedicated to Space Station activities (e.g., TDRSS and NASCOM 
support all near-earth orbiting NASA spacecraft). These factors pose complex management and integration problems for the 
Program. To assist in resolving these problems, the Task Forte recognized the need to have a single organization responsible for 
definition and control of SSIS architecture requirements. 
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• An assembly facility for the assembly of large space 
structures or spacecraft, or integration with orbital 
transfer systems; 

• A servicing facility where spacecraft and payloads 
may be resupplied, maintained, upgraded or 
repaired; 

• A transportation node for deployment of spacecraft 
into different operational orbits using both 
throwaway and reusable orbital transfer systems; 

• A manufacturing testbed for "scale-up" of 
equipment and processes for the on-orbit production 
of products which cannot be made on Earth; and 

• A storage depot for experiments, equipment, 
consumables, and spare parts. 


II. B. 2. Operations Activities 

A typical day’s activity for the manned base will be 
analogous to the operation of a multifunctional 
research and development complex on Earth. The 
major difference, of course, will be its location (in space 
and physically separated from its support facilities) 
and the unique requirements it places on those who 


maintain and use it. Typical operations activities for 
the manned base and unmanned platforms are depicted 
in Figures II-2 and II-3. These include: operations and 
utilization planning (determining who uses which 
resources and for what purposes, and planning for long 
term systems evolution); logistics operations support 
(the prelaunch activities associated with preparing the 
crew, consumables, and user instruments for launch to 
either the manned base or a platform and postlanding 
activities upon return); space operations (activities 
which transpire in orbit); and space operations support 
(ground-based activities which support or control 
manned base and platform on-orbit operations). 

Utilization and Operations Planning 

Before the ’’real-time” operations and support functions 
occur, there must be an operations and utilization 
planning process for determining policies and 
procedures for allocation of resources, selection of 
users, and systems evolution. NASA and its partners 
will meet routinely to assess whether the Program is 
meeting its broad goals and objectives, and to make 
long term plans with regard to utilization of the 
Station and potential addition of new capabilities. 
Users and Program officials will meet regularly to 
develop manifests (a schedule of when user payloads 
will be launched or returned from one of the orbiting 
spacecraft). Manifesting procedures will include both a 
’’standard" cycle and a so-called "quick is beautiful" 



Figure II-2 Manned Base Operations Infrastructure 
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Figure II-3 Platform Operations Infrastructure 


cycle. The standard cycle will cover the allocation of 
payload resources, proposal and selection of payloads, 
performance of engineering analyses, assignment of 
the payload to a particular Station element and flight 
"increment ", 10 and development of successively more 
detailed timelines for managing the payloads on orbit. 
It is anticipated that a certain percentage of the 
Program’s capabilities will be reserved for so-called 
"quick is beautiful" payloads. These are payloads 
which need expeditious launch to respond to a unique 
research opportunity (e.g,, the appearance of a 
supernova), or to allow researchers to operate payloads 
which require a minimum of time to develop from the 
design phase to flight with a minimum of resources, 
and hence can be accommodated late in the 
manifesting process. 

The user community screens candidate payloads and 
makes the final selection of specific payloads to be 
placed on the Station manifest. As researchers in the 
U.S. and abroad develop and build instruments and 
payloads, they will be supported by Program 


documentation and personnel to ensure their payloads 
comply with Program requirements. This support is 
provided by the Program at the user's location, the 
launch sites, and at geographically dispersed Science 
and Technology Centers . 11 The Science and Technol- 
ogy Centers will conduct payload to rack integration, 
and perform functional operations verification of the 
payloads. Staff from the Office of Safety, Reliability, 
Maintainability & Quality Assurance will conduct 
regular independent reviews to ensure that safety and 
quality standards are met. 


Logistics Operations Support 

For U.S. launches, integration of flight hardware 
resupply and maintenance activities will be conducted 
by a single Logistics Operations Center (LOG) located 
at the launch site. Payload racks and payload interface 
adapters (PIAs-for external payloads) which have 
been integrated at Science and Technology Centers, 
"stand-alone" payloads, and logistics material will be 


10 A Space Station increment is defined as the length of time which transpires between STS visits. This term applies to both the manned 
base and the platforms (although platform increments can be much longer than those for the manned base). 

u The Science and Technology Centers may be located at NASA, partner , or user sites. These Centers are certified by the Program as 
complying with Program and STS safety , interface, and operations requirements. 
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delivered to a Space Station Processing Facility (SSPF) 
for final checkout and integration into the STS or 
expendable boosters. Reusable equipment, such as 
payload equipment racks, will be refurbished and 
maintained between flights. Similar launch support 
activities may also occur at the partners' launch sites, 
coordinated by the LOC. 

The Space Station Program will maintain continuous 
interaction with the Shuttle program (and possibly 
other space transportation systems). The Shuttle is 
integral to Station deployment and operations; it is the 
gateway through which system and user hardware. 
Station logistics, and crew must pass. 12 Hence, to the 
maximum extent feasible, the schedules and proce- 
dures for the two programs must be closely aligned to 
avoid duplication of effort and to optimize the efficiency 
of the entire space infrastructure. 13 


Space Operations 

The "productive activity" will take place in orbit. An 
international team of astronauts will monitor and 


report on approximately 100 major experiments in the 
manned base's labs, resource nodes and attached to its 
truss. Some may participate in human biomedical and 
physiological experiments involving blood and tissue 
samples and/or special exercises or motions. Others 
will tend laboratory animals and plants. Payload 
Scientists sponsored by commercial firms may engage 
in highly proprietary research in fields such as genetic 
engineering or advanced semiconductor deposition 
techniques. Scientists may conduct live broadcasts of 
space research, working in real-time with ground- 
based researchers, or explain their activities in any one 
of several languages to students on the ground. Some 
of the experiments onboard the manned base will be 
proprietary, requiring some form of physical 
separation of experiments, data and communications 
channels, and provision of dedicated crew support. 

User activities outside the manned base will utilize 
both telerobotic and astronaut extra-vehicular activity 
for payload servicing, changeout, or the assembly of 
large structures and spacecraft. Often the activity will 
require a combination of both intra and extra-vehicular 
activities (IVA and EVA). 


SPACE STATION AUTOMATION 

Automation of Space Station systems both on the ground and onboard l and the use of robotic hardware to relieve crews of tedious 
and/or dangerous tasks, should be a central aspect of the Space Station design studies. Decisions must be made as soon as possible on 
which systems are to be automated on the initial Station , on which robotic technologies are required early, and on the hooks and 
scars which must be added to the initial Station design to allow the addition of further automation and robotics (AM) during 
evolutionary phases of the Program , In order to facilitate such decisions, the Phase CID design efforts must include studies o f AM 
systems from an operational arid life cycle cost basis. At the very least the initial Station must provide the systems required to acquire 
the M knowledge base*' necessary to build automation capability as the Station evolves. 

In making these statements, the Task Force concurs with the conclusions of the Advanced Technology Advisory Committee (ATAC), 
which completed its report of automation and robotics applications on the Space Station in April 1985. These conclusions were: 

• Automation and robotics should be a significant element of the Space Station Program. 

• The initial Space Station should be designed to accommodate evolution and growth in automation and robotics. 

• The initial Space Station should utilize significant elements of automation and robotics technology. 

• Criteria for the incorpora tion of AM technology should be developed and promulgated. 

• Verification of the performance of automated equipment should be stressed, including terrestrial and space demonstrations to 
validate technology for Space Station use. 

• Maximum use should be made of technology developed for industry and Government. 

• The techniques of automa tion should be used to enhance NASA *s management capability. 

• NASA should provide the measures and assessments to verify the inclusion of automation and robotics in the Space Station , 

• The initial Space Station should utilize as much automation and robotics technology as time and resources permit 

• An evolu tiona ry sta tion should achieve, in stages, a very high level of advanced automation. 

• An aggressive program of long-range technology advancement should be pursued, recognizing areas in which NASA must lead, 
provide leverage for, or exploit developments. 

• A vigorous program of technology transfer to U.S. industries and research and development communities should be pursued. 

• Satellites and their payloads accessible from the Space Station should be designed, as far as possible, to be serviced and repaired 
by robots. 

While acknowledging the great potential of AM in the Space Station Program, the Task Force cautions that increased Station 
automation should be treated not as an end in itself, but only as a means to relieve the onboard crew of tedious, repetitive or 
dangerous tasks and/or as a means of decreasing Station operating costs. 


I2 The SSOTF assumed that the NASA Space Transportation System (STS) will serve as the primary transportation system in support 
of the Station. The Shuttle and Station systems were assumed to be intimately interconnected, with substantial synergy in operations. 
However , the SSOTF was instructed not to preclude the use of other transportation vehicles (e.g., expendable launchers), and to evaluate 
whether or how such systems would improve the operational efficiency of the Station. It was also assumed that other manned space vehicles 
could be used in conjunction with the Station as long as those vehicles were made to be compatible with Station interfaces and procedures. 

13 In a traditional NASA mission (e.g., launch of an interplanetary spacecraft), the technical interface needs to be defined only once, the 
payload needs only one manifest, and once the spacecraft is deployed, there is little, if any, continuing interaction. STS/Station interfaces 
are considered as a special topic in Section TV.E. 
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II.C. CHARACTERIZING THE USER 
COMMUNITY 

Space Station operations will be heavily influenced by 
the user community. Hence, it is necessary to charac- 
terize the utilization parameters for Station services in 
order to understand how Station operations should be 
structured. (See Table 11-2.) 

II.C.L Demographic Categorization of Users 

Traditionally, NASA customers have been grouped by 
sponsor. In this manner users can be easily distin- 
guished in terms of their broad goals, means of support, 
and overall priority for access to NASA facilities or 
services. Dividing the Space Station user community 
along such demographic lines results in the following 
general groupings: 

NASA Researchers 

This group encompasses the traditional NASA space 
research community sponsored by the various internal 
NASA program offices (Office of Space Science and 
Applications, Office of Aeronautics and Space 
Technology). Research activities are conducted under 
NASA auspices and paid for through the NASA 
budgetary process. 


NOAA 

The National Oceanographic and Atmospheric 
Administration has worked very closely with NASA in 
the areas of meteorology and earth observations. Until 
recently, NASA has traditionally been the developer or 
procurement agent for NOAA's weather and earth 
resources satellites, which are turned over to NOAA 
once they have been launched and completed on-orbit 
checkout. Operations are funded through the Depart- 
ment of Commerce. 

Academic/Science Users 

This group consists of users sponsored by academic or 
other non-profit research institutions (or individuals). 
Historically, there have been few independent aca- 
demic users. Most have operated under NASA support. 
However, the potential for greater independent 
academic involvement in space will exist once the 
Space Station enters its Mature Operations Phase. 

Department of Defense 

DOD utilization of the Station could have significant 
operational impacts which need to be clearly defined 
and anticipated. The most significant issue to be 
resolved is the potential requirement for highly secure 
DOD operations, and the impact of this requirement on 


DEMOGRAPHIC SPACE 
STATION USER GROUPS 
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Table II-2 Characterizing The User Community 
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In addition to performing user activities, the crew of 
the manned base will have responsibilities for the 
operation, maintenance, repair and upgrade of many 
core systems. This would include: examination of the 
external structure using the MSC and the closed circuit 
television (CCTV) system; command and control of 
unmanned free-flyers in the manned base's command 
and control zone (within 20 nm); routine maintenance 
on internal systems such as power, ECLS, data 
management and communications; and operation of 
the manned base's attitude control and guidance 
systems. EVA activities will include repair and main- 
tenance of external components, support for Shuttle 
logistics resupply, and servicing and repair of external 
payloads, the co-orbiting platform and other spacecraft. 

The crew of eight astronauts will normally be split into 
two teams working alternating twelve-hour shifts. 
(Each shift will include nine hours of work and three 
hours of on-call time.) Normal work will be scheduled 
for six days per week. The crew rotation cycle is likely 
to be variable dependent upon tasks to be performed 
during a given increment and STS support constraints, 
but it is expected that half the crew will be changed out 
with each Shuttle visit. Crews will include career 
astronauts (employed by the SSP) as well as non-career 
astronauts supplied by users. Crew skills will be based 
on Station requirements and are likely to differ from 
STS skills, since some pilot skills will not be required 
for the Station. 

The crew will conduct activities both inside (IVA) and 
outside (EVA) of the manned base. Career astronauts 
will perform all of the manned base systems 
operations, all EVA operations, and will support users. 
Non-career astronauts will be flown when unique 
payloads require them. However, non-career astro- 
nauts will also be required to support other users, since 
crew time will be a scarce resource and there will be 
many payloads requiring support. 


Space Operations Support 

Space operations support facilities will support 
onboard crew and manned base systems by performing 
those functions which can most effectively be conducted 
on the ground. In effect, while logistics support covers 
the transportation of all physical material to and from 
orbit, space operations support covers the preparation 
and "transport" of system and user commands and data 
to and from the Station using data relay satellites. 14 

A Space Station Support Center (SSSC) will monitor 
the manned base's systems status, and relay commands 
to support the operations and ensure that safety 
requirements are met. Expert systems and other 
advanced computer technologies will be developed to 
support efficient Station operations. These systems 
will proliferate as the Station evolves, reflecting both 
continued advances in the capabilities of such systems, 
and greater understanding of the performance of 


manned base systems (which will result in the 
expansion of automated support to routine crew 
operations and support of time- critical events). 

A Payload Operations Integration Center (POIC) will 
support the activities of the user community in 
integrating payload operations into the manned base. 
Users will work with Program personnel whose 
function is to guide the user through the detailed 
process of developing compatible payloads according to 
Program specifications. Experiment and payload 
development will occur at a variety of user facilities 
throughout the world, but payload operations for the 
manned base will be coordinated by the POIC. 

Users will have a great deal of flexibility in organizing 
for their own operations. They may work out of their 
existing facilities, or may group together on a regional 
or disciplinary basis to share facilities and resources. 
Those users wishing to conduct proprietary operations 
will have the ability to encrypt their data, subject to 
minimal Program safety oversight. Many users will 
operate in a "telescience" mode, directly interacting 
with their experiments using the Program's RF links 
and networking capabilities. 

A Platform Support Center (PSC) will combine the 
system and user support functions for the unmanned 
platforms. The PSC will have authority for all 
command and control functions for the platforms, 
except when they are in proximity to the manned base 
or the STS. The PSC contains two functional 
operations centers. These are the Platform Payload 
Operations Center (PPOC) and the Platform Transfer 
Operations Center (PTOC). The PPOC performs both 
systems control and user coordination functions (ana- 
logous to the SSSC and the POIC roles). The PTOC is a 
unique function associated with preparing and 
conducting servicing operations on the platforms. The 
period of time during which the platform is taken "out 
of service" for these operations is called Transfer 
Operations. 


A number of Engineering Support Centers (ESCs) will 
support the SSSC and PSC. These will initially be 
synonymous with the program's hardware develop- 
ment centers in the U.S. and abroad. The ESCs will be 
the repository of information on the technical charac- 
teristics of the flight hardware. The ESCs will support 
anomaly resolution and provide operations analyses 
related to their areas of expertise. 


The Program will also coordinate and manage 
simulation and training facilities for the manned base 
crew, ground-based support personnel and Station 
users. These facilities will provide the "off-line" 
education in Station and selected payload systems 
which must be learned prior to actual space operations. 


14 The manned base will be linked to the ground through the Tracking and Data Relay Satellite System (TDRSS). The U.S. platforms 
will also be linked to the ground via the TDRSS; European (and possibly Japanese platforms at a later date) may be linked through 
European or Japanese data relay satellites. 
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non-classified users. At present, the DOD has not 
defined any operational uses for the Station, but has 
stated its interest in using the Station to support 
proprietary research activities. 

The SSOTF assumed that the Space Station is a 
civilian program, in which all operations will be 
consistent with the NASA charter and existing 
international agreements to which the United States is 
a party. No unique military requirements were 
considered in selecting alternatives to the framework. 
DOD was treated as a potential user whose 
requirements were equivalent to those of any other 
proprietary user. 


Commercial Users 

This group is composed of private firms which plan to 
conduct research and development, and/or perform 
pilot production activities taking advantage of the 
characteristics of the space environment. These users 
are much more sensitive to scheduling and proprietary 
operations considerations, since they must meet 
financial and competitive business goals of the 
marketplace. In comparison to the traditional space 
research community, many of these users have a low 
level of space experience, and require support in 
formulating their space activities and meeting NASA 
procedural requirements. 

The SSOTF did not address privatization or 
commercial provision of Station operations services 
explicitly, but did not preclude private sector 
participation in the operations framework. In the 
framework developed by the SSOTF, it is assumed that 
all Station elements are operated by the partners with 
NASA in a lead role, but the framework does not 
preclude the option to transition some activities to the 
private sector. 


International Users 

ESA, Japan and Canada plan to sponsor users from 
their own space agencies, other government facilities, 
private industry, and academia. These users generally 
share the resource requirements identified for the 
corresponding category of U.S. users. However, they 
pose additional operational demands based on policy 
issues (e.g., technology transfer, different national 
legal codes), and require additional logistical interfaces 
to accommodate their needs. 

Users may also come from nations which are not Space 
Station partners. However, these users will have to be 
sponsored by one of the Space Station partners, and 
their resource requirements will be drawn from the 
sponsor's allotment. 


Other U.S. Government Agencies 

In addition to NOAA and the DOD, a number of other 
government agencies are expected to become users of 
the Station in the future. The area of greatest early 
interest lies in earth observing missions. Landsat data 


has already been extensively utilized by the Depart- 
ment of Agriculture, and other uses in the fields of 
material and life sciences and technology development 
are expected to be pursued by various government 
agencies. 

II.C.2. Disciplinary Categorization of Users 

Users must also be categorized by discipline in order to 
evaluate technical requirements. (See again Table II- 
2.) Classifying users in this manner provides the 
following breakdown . 


Materials Science 

Materials science is one of the most promising fields 
planned for the Space Station's facilities, and includes 
users from all the demographic categories except 
NOAA. The field encompasses research and pilot 
production activities, including: (1) biological, organic 
and pharmaceutical substances; (2) inorganic crystals; 
(3) advanced glasses and ceramics; (4) metals and 
alloys; (5) combustion technologies; and (6) polymer 
chemistry. 

Microgravity science users often have significant 
power requirements and need access to a high-quality 
microgravity environment, but are insensitive to other 
operational characteristics such as pointing orien- 
tation. Most of these activities can be conducted best 
through the use of an orbiting laboratory facility with 
man in-the-loop. 


Life Sciences 

The study of microgravity effects on living organisms 
(including man) is a second area of growing interest. 
This interest is focused in three directions: 
understanding subtle physiological processes which are 
masked by gravity; research into phenomena such as 
Space Adaptation Syndrome and osteoporosis, which 
provides insight into maladies present on Earth; and 
research into the long term effects of weightlessness (a 
prerequisite to long duration manned flights). Such 
activities are currently of primary interest to NASA, 
the partner governments, and to the academic 
community. DOD and private sector interest may grow 
as the capabilities of the manned base become more 
apparent. Such activities typically require a high level 
of manned interaction in a laboratory environment. It 
is anticipated that such life science research will 
receive a high priority during the early days of the 
Program to support the extension of crew stay time on- 
orbit up to 180 days and beyond for Station missions, 
and in preparation for supporting manned lunar and 
planetary exploration. 


Servicing and Assembly 

All user communities have expressed interest in 
satellite and attached payload servicing and assembly 
capabilities which would extend satellite or other 
payload lifetimes, reduce mission costs, or allow the on- 
orbit assembly of structures too large to be deployed in 
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a single launch. Since the experience level for such 
activities is still quite rudimentary, it is expected that 
government users will pace the development of this 
activity. These activities call for provision of a man- 
supported facility which can act as a base for on-orbit 
operations and infrastructure support. 

Technology Development 

Technology development is a broad category that cuts 
across many disciplines and includes the development 
and demonstration of advanced space technologies such 
as robotics systems and solar dynamic power systems. 
Successful missions raise the "technology baseline" for 
new programs. For example, experiments with more 
powerful, compact batteries pave the way for their 
incorporation into new, more capable (or less costly) 
spacecraft. The majority of missions in this area would 
be conducted by NASA, the partners' space agencies, 
and the DOD. Technology development missions would 
utilize the full range of manned and unmanned Station 
assets. 


Earth Observations 

The field of earth observations consists of activities 
related to the study of the structure and resources of 
the earth and its environment. Activities in this 
category demand high pointing accuracy and low- 
disturbance, and are best performed on unmanned 
platforms (usually in polar orbits). All of the demo- 
graphic user groups are represented here. 

Astronomy, Astrophysics & Planetary Physics 

The Space Station will support space observational 
sciences, including astronomy and astrophysics, and 
planetary physics and exploration. The use of man for 
experiment support, while often useful, is not usually 
critical (although some planetary physics experiments 
require manned support). Most of the users in this 
category will come from NASA and the partners' space 
agencies, and the academic community, and will 
conduct most of their activities using attached 
payloads or unmanned platforms. 


Commercial Production 

Private firms may also engage in pilot production of 
materials in space. This industrial activity may 
generate much greater resource demands and will 
require a higher quality microgravity environment 
than smaller-scale research and development experi- 
ments. As a result, commercial production will usually 
require a dedicated platform catering to the specific 
needs of the commercial user. At present, it is not 
evident whether the best approach is to utilize 
unmanned or man-tended platforms. 

Communications 

The Station will also serve as a base for advanced 
telecommunications and data transmission projects. 
Outside of technology development missions, the Space 
Station is not expected to play a primary role in space 
communications activity. 


Technical requirements of Space Station users have 
been addressed in a number of previous studies, which 
have been instrumental in the definition of the current 
Station configuration and are summarized in the Space 
Station Mission Requirements Data Base. Based on 
these studies, the Station's capabilities can be defined 
in terms of specific resources which support user 
requirements. These capabilities are identified in 
Table II-3. Table II-4 lists those resources that have 
been identified as drivers from previous customer 
accommodation analyses, presented in order of priority 
to each user group. In this way, key Station 
capabilities can be identified based on the commonality 
of the requirements across user groups. 

Procedural requirements reflect the preference of the 
user to maintain space operations under conditions 
similar to those used on Earth. Given the demographic 
diversity of users, it will not be possible to accomplish 
this goal completely, but it must be kept in mind in 
developing the user integration process (i.e., the 
processes and procedures that the user and the Station 
Program must implement to carry the payload through 
completion on the Station complex). 

Although different procedural requirements will be 
more important to some groups than to others, a 
number of common requirements can be identified: 

• User control of payload selection and resource 
allocation; 

• A single point of contact within the Space Station 
program to which the user can turn for guidance in 
dealing with the various interfaces at each 
organizational level of the Program; 

• Simple, standardized interface and integration 
procedures; 

• Concise, accurate, and current documentation and 
documentation requirements, and easy access to 
information; 

• Options ranging from nearly complete autonomy of 
user payload operation to complete user reliance on 
Station services; 

• Clearly defined, consistent and reasonable 
standards in hardware, software, safety and 
services; 

• Strict adherence to schedules and timelines, 
wherever possible; 

• Flexibility in access to facilities in supporting user 
"windows of opportunity"; and 

• User representation in decisions affecting the 
operation and viability of his payload. 


While the above requirements are important to all 
users, some user groups will generate unique 
requirements. The most important of these are: 
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ELECTRIC POWER 
GENERATION LEVEL 
STORAGE (PEAK) 
MANAGEMENT & 
CONDITIONING 

MANNED INTERVENTION 
EVA 
IVA 

REMOTE MANIPULATORS 
AUTOMATION 

OPERATIONS/PROTOCOL 
SCHEDULED ACCESS 
EVENT-DRIVEN PRIORITY 
DEDICATED PERSONNEL 

EXTERNAL ENVIRONMENT 
HIGH VACUUM/LOW 
CONTAMINATION 
RADIATION SHIELDING 

CORE UTILITIES 

DATA MANAGEMENT (DMS) 
COMMUNICATIONS 
FLUID MANAGEMENT 
THERMAL MANAGEMENT 

ON-ORBIT SERVICING 
FREE-FLYERS 
SPACECRAFT/VEHICLES 
ASSEMBLY 

GRAVITY LEVEL 

MICROGRAVITY (AMBIENT) 
VARIABLE GRAVITY 

ACCESS TO PLATFORMS 
CO-ORBITAL 
POLAR 

RESEARCH SECURITY 
DATA 

HARDWARE 

INTERNAL ENVIRONMENT 
PRESSURIZED VOLUME 
SPECIAL ENVIRONMENT 
HAZARDOUS MATERIALS 

ACCESS TO ATTACHED PAYLOADS 
EARTH OBSERVATION 
ASTRONOMICAL OBSERVATION 
UNPRESSURIZEDATTACHMENT 
PRESSURIZEDATTACHMENT 

LOGISTICS 

VOLUME/MASS 
RESUPPLY INTERVAL 
ON-ORBIT STORAGE 
WASTE MANAGEMENT 
OVERSIZED PAYLOADS 


Table II-3 Space Station Capabilities For Users 


MATERIALS 
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SERVICING & 

OBSERVATIONAL 

PHYSICAL & 

COMMERCIAL 

SCIENCE 

SCIENCE ( 

ASSEMBLY 

(EARTH & ASTRO) 

PLANETARY SCIENCE 

PILOT PRODUCTION 

Electric power 

Pressurized 

volume 

EVA-crewtime 

Communications 

System 

Access to surge/pulse 
electric power 

Electric power 

High quality 
micro-g 

Special 

pressurized 

environments 

Access to remote 
manipulators 

Access to polar 
platform 

IVA-crewtime 

High quality 
micro-g 

IVA-crewtime 

IVA-crewtime 

Fluid manage- 
ment system 

Servicing for 
platforms 

Pressurized volume 

Pressurized volume 

Thermal manage- 
ment system 

Waste manage- 
ment system 

Platform and 

spacecraft 

servicing 

Event-driven 
priority access to 
resources 

Special pressurized 
environments 

IVA-crewtime 

Pressurized volume 

Large volume 
logistic s support 

IVA-crewtime 

Electric power 

Power management 
and conditioning 

Need for scheduled 
access 

Hazardous 
materials handling 

Electric power 

Large structures 
assembly and 
support 

Access to 
attached payload 
space 

Variable gravity 
levels 

Fluid, thermal and 
waste manage- 
ment systems 

Data management 
system 

Variable gravity 
levels 

Communications 

system 

High quality 

vacuum 

environment 

Thermal manage- 
ment system 

Large volume 
logistics support 


Table II-4 Prioritized Capabilities By User Discipline 
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• Availability of rapid-response payload accommoda- 
tion procedures ("quick is beautiful"): Some users, 
such as commercial firms wishing to take advan- 
tage of a proprietary opportunity, or government 
researchers pursuing an unexpected or unique 
scientific window of opportunity, will desire rapid 
access to Station facilities. 

• Proprietary operations support: Commercial firms 
and the DOD will require unique operational 
procedures for the protection of proprietary 
activities. Proprietary requirements will affect 
crew operations, ground and onboard handling of 
user and Station communications and data manage- 
ment, and the prelaunch/postlanding processing 
approach to the payload. 

• Late pad access, early return capability, and rapid 
post-landing access: Many experiments, notably 
those in life sciences, will require "last-minute" 


access to payloads on the launch pad. Likewise, 
many experimenters may wish to quickly return 
experiment samples which have behaved in 
unanticipated ways for earth-based analysis. 
Finally, many payloads (again, life sciences are a 
notable example) may require early deintegration 
from the STS upon return from space. 


The SSOTF had to incorporate such specialized 
procedural requirements into the design for the 
operations framework, along with the more traditional 
technical user requirements. Together with the 
definition of the key user groups and their broad 
facilities requirements, these technical and procedural 
requirements form the baseline for defining an 
operations framework. 
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I I 

• RESOURCE AVAILABILITY PLANNING 

• SYSTEMS OPERATIONS • MAINTENANCE 
PLANNING 

• USER/SYSTEM INTEGRATION PLANNING 

• TRANSPORTATION SERVICES PLANNING 

• LOGISTICS SUPPORT PLANNING 

• DATA SYSTEMS SERVICES PLANNING 



• PAYLOAD ENGINEERING • INTEGRATION 

• USER ACCOMMODATION SERVICES 


SYSTEMS OPERATIONS 
ANO USER OPERATIONS 
SUPPORT 


SYSTEMS ENGMEERMG 
A INTEGRATION 

MANNED BASE 

PLATFORMS 


MANNED BASE 

PLATFOBMS 


• SPACE SYSTEMS OPERATIONS • GROUND SUPPORT SYSTEMS 

SUSTAINING ENGINEERING AND 

• USER OPERATIONS SUPPORT CONFIGURATION CONTROL 


• PRE/POST FLIGHT OPERATIONS 

• INTEGRATED LOGISTICS SUPPORT 


• INFORMATION SYSTEMS SUSTAINING 
ENGINEERING AND CONFIGURATION 
CONTROL 


• INFORMATION SYSTEM OPERATIONS 

• OPERATIONS SUPPORT FACILITIES 
SUSTAINING ENGINEERING (MftO) 

• CONFIGURATION CONTROL OF 
OPERATIONS PLANS, PROCEDURES, AND 
DATA 


• DATA SYSTEMS INTERFACE SUSTAINING 
ENGINEERING AND CONFIGURATION 
CONTROL 

• SPACE SYSTEMS ANO PAYLOAD 
INTERFACE SYSTEMS SUSTAINING 
ENGINEERING AND CONFIGURATION 
CONTROL 


• OPERATOR TRAINING 


Figure III- 1 Operations Functions 


tiations or evolution planning will be "requirement- 
driven” and occur on a less frequent basis. These 
functions apply to the broad conduct of both user and 
SSP operations, and hence serve as the strategic frame 
within which all activities occur. Operations control 
functions also include the activities which monitor the 
overall resources for the Program. Budgets must be 
established for specific activities, and Program expen- 
ditures must be monitored and controlled in order to 
ensure that funding achieves desired objectives in an 
efficient manner. 

User Operations 

User Operations are broken into four subcategories: 
Resource Allocation; User Selection; Payload Develop- 
ment and Integration; and Payload Operations. These 
categories have a temporal relationship for an 
individual user: from the announcement of a flight 
opportunity to the performance of an experiment. 
From the Program perspective, all of the functions will 
be performed concurrently, as multiple users "work 
their way through the system." 


Resource Allocation: Resource allocation includes all 
of the tasks for determining how the Station’s available 
resources will be distributed among different user 
groups. Allocations will be made among the partners 
at a "national" level by MOUs, and are thus a function 
of the Program. However, the subsequent distribution 
of the partner resource shares to differing user groups 
will be a function conducted by the users. The SSOTF 
judged that the users were in the best position to 
evaluate the merit of which activities should be 
performed. 


User Selection: The user selection process consists of 
all of the user tasks performed by the sponsoring 
organizations for deciding what payloads should be 
flown on the Station. User selection usually involves 
some form of peer review process. The Program then 
accepts those experiments that are consistent with 
ongoing and proposed activities by conducting engi- 
neering analyses which verify that a payload meets 
system and user safety requirements, and will not 
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III. SPACE STATION OPERATIONS 


This chapter presents the Recommended Framework 
for Space Station operations. The core of the Task 
Force effort, the Framework lays out the management 
and organizational approach which the Task Force 
believes best meets the Program objectives outlined in 
Chapter II. Section HLA provides a brief synopsis of 
the operations functions which must be performed to 
meet Program objectives, and presents the operations 
evaluation criteria which the Task Force used to select 
among various framework options to perform the 
functions. The introduction section (IELB.l) presents 
the management approach for the Framework and 
synopsizes major themes; the following subsections 
provide the details of the Framework for the manned 
base and the unmanned platforms respectively. 1 
Section III.C develops the organizational structure 
(including assignment of roles and responsibilities) 
which the SSOTF recommends for implementing the 
Recommended Framework. Section Ut.D summarizes 
a User Integration Scenario which the Task Force 
performed as a "sanity check" on the Framework to 
insure that it adequately met users' needs, and to 
illustrate the functioning of the Framework in real 
life. 2 

III.A. OPERATIONS FUNCTIONS 

An operations function is a task or set of tasks required 
to sustain space operations. 3 In the broadest of 
definitions, any activity associated with operations can 
be considered an operations function (for example, 
Congressional approval of the NASA operations 
budget). The Task Force, however, defined operations 
functions in a more restrictive sense: those activities 
performed by the SSP and users which (1) keep the 
Station elements (both ground and space-based) in 
working condition; and (2) support productive 
utilization of Program assets. 


The Task Force consensus was that the Space Station 
Program did not involve any completely new 
operations functions other than regularly scheduled 
resupply and changeout of user payloads. While Space 
Station is complex (both in "quantitative" terms 
relating to its size, and "qualitative" terms relating to 
its multiple uses), previous NASA missions have 
already mapped out similar operations functions. 4 
What is different is how NASA and its partners must 
organize to perform those functions, and the greater 
degree of flexibility which the operations framework 
must incorporate to meet its diverse and changing day- 
to-day tasks. Likewise, the Program’s operations 
framework must embody a life cycle cost orientation 
consistent with its long mission. 

III.A. 1. Operations Functions Categories 

Space Station operations functions can be defined in 
terms of categories of activity (related subfunctions). 
These categories are presented in Figure HI-1. They 
fall naturally into three areas: Operations Oversight, 
Program Operations and User Operations. 5 The 
Safety, Reliability, Maintainability and Quality 
Assurance (SRM&QA) function is interwoven in both 
user and systems operations. 6 


Operations Oversight 

NASA and its partners will need to establish, monitor 
and revise overall Program policies as required for 
Space Station operations. These functions establish 
Program- wide objectives and assignment of roles and 
responsibilities for the partners. Many of these 
activities, such as budget planning and program 
performance and cost assessments, will be continuous 
in nature. Others, such as specific international nego- 


J Wit/i the exception of unique activities necessary to support mans presence in space , the operations functions necessary to conduct 
manned base and platform operations are essentially the same. However, there are differences in the way the functions are performed and in 
the frequency of performance. These differences led to the development of separate recommendations for the management, planning, and 
execution of manned base and platform operations. 

2 Further details on the Recommended Framework can be found in the various Panel reports. 

3 This definition separates activities involved in design, development , test and engineering (DDT&E) from operations. Phase C 
development efforts are not operations functions. However, the dividing line between DDT&E and operations can be very fine. For example , 
while building an additional module for the manned base would not be an operations function, activities associated with defining the 
requirements for the new module, approving its inclusion in the Program, engineering and operations assessments of the impact of the new 
module on the existing configuration, and manifesting the launch and integration of the new module, would be operations functions. 

4 The operations functions which will be required for the manned base have already been performed in the manned space flight program 
(especially in the Skylab, STS and Spacelab programs); platform operations are similar to previous unmanned missions. 

5 This chapter presents general descriptions of operations functions. Detailed "input-output'* functional flows are provided in Appendix 
B. The Task Force focused its effort on those functions which "reside" in the Space Station Program, and dealt with user functions only to 
the extent of defining the interface requirements from the Program's perspective. The Task Force felt that the development of user roles, 
responsibilities and organization are best addressed by the users themselves. Note as well that these are operations functions only; 
requirements associated with hardware development (DDT&E) are included only to the extent that they affect ongoing operations. 

6 SRM&QA is the responsibility of users and Program personnel at all levels of planning and activity. Likewise, an independent 
"watchdog" (i.e., non-SSP) safety office will monitor users and Program personnel. (See Section III.C. 2 for a presentation of SSP 
relationships with the SRM&QA office.) Hence, this function is listed separate from User and Program operations. The importance of this 
independent function in NASA has been institutionalized in the Office of Safety, Reliability, Maintainability and Quality Assurance at 
NASA Headquarters. 
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framework which best enabled the performance of 
these functions (and their related subfunctions) by the 
appropriate management levels of the operations 
organization (as depicted in Table EQ-l). As there were 
a number of framework options available which would 
appear to be at least feasible, the Task Force devised a 
set of option evaluation criteria which were in large 
part directly or indirectly correctable to overall 
Program goals. Each option was evaluated, in a 
relative sense, on how well it satisfied these evaluation 
criteria and, hence, Station Program goals. 7 * * * 11 The six 
evaluation criteria chosen by the SSOTF address an 
option's ability to support and enhance: (1) Program 
control; (2) Program safety and system integrity; (3) 
effective user operations; (4) substantive international 
participation; (5) assembly and evolution; and (6) 
operations cost effectiveness. 

Program Control: The most fundamental criterion is 
whether or not the option is manageable; i.e., is it 
controllable and will it work? Any option for Station 
operations must be "codified" in a management 


structure which establishes proper levels for decision- 
making, accountability and control. Authority and 
chain of command must be clearly established so that 
any individual in the Program knows whom to turn to 
in both normal and off-nominal situations. This 
includes not only the establishment of hierarchical 
roles and responsibilities for Headquarters and Field 
Center operations organizations, but also a centralized 
management oversight function supported by a well- 
designed management information system. 


Program Safety and System Integrity: Program safety 
and system integrity are of equal importance to 
Program Control. The value of the crew and the on- 
orbit hardware, and the long-term and continuous 
operations environment for the Program dictate that 
safety be considered a priority in the operations 
environment. 12 Hardware and software must be built 
to high reliability, redundancy and operability 
standards which are technically specific, measurable 
and predetermined. Standards of performance for crew 



PROGRAM INTEGRATION FUNCTIONS 


1. INTEGRATED OPERATIONS PLANNING 
(SEPARATE FOR MANNED BASE 7 
PLATFORMS EXCEPT FOR COP SERVICING) 

1 A. TACTICAL OPERATIONS PUNNING 
(MANNED BASE A PUTFORMS) 

IB. MANNED BASE INCREMENT PUNNING 
(INCLUDES COP SERVICING) 

2. USER INTEGRATION & ACCOMMODATION 
SERVICES 

3. MANNED BASE ft SUPPORT SYSTEM 
ENGINEERING & INTEGRATION 

4. PUTFORM 4 SUPPORT SYSTEMS 
ENGINEERING A INTEGRATION 

5. INFORMATION & NETWORK SYSTEMS 
ENGINEERING & INTEGRATION 

6. SAFETY, RELIABILITY/MAINTAINABILITY A 
QUALITY ASSURANCE 

7 BUDGET ADMINISTRATION A COST 

CONTROL 

a. INTEGRATED LOGISTICS SYSTEMS 

9. CONFIGURATION CONTROL (SPACE 

SYSTEMS,fNTEIffAClNGGAQUI^X$Y5TEMS, 

PAYLOAD IffTfefcFACES, A#* PROGRAM 
INTEGRATION-LIVE L OPERATKft$PLAN$) 


PROGRAM EXECUTION FUNCTIONS 


1. MANNED BASE SYSTEM OPERATIONS 

2. MANNED BASE USER OPERATIONS SUPPORT 

3. PLATFORM(S) SYSTEM OPERATIONS 

4. PUTFORM USER OPERATIONS SUPPORT 

5. PREFLIGHT/POSTFLIGHT OPERATIONS 

6. INTEGRATED LOGISTICS OPERATIONS 

7. INFORMATION SYSTEM OPERATIONS 

8. SUSTAINING ENGINEERING 

8A. SPACE SYSTEMS 
8B. GROUND SYSTEMS 
8C. PAYLOAD INTERFACE ENGINEERING A 
INTEGRATION 

9. CONFIGURATION MANAGEMENT 

9A. SPACE SYSTEMS 
9B. GROUND SYSTEMS 
9C PAYLOAD INTERFACES 
9D. EXECUTION-LEVEL OPERATIONS PUNS 
A PROCEDURES (INCLUDING CONTROL) 

10. SAFETY. RELIABILITY/MAINTAINABILITY A 
QUALITY ASSURANCE 

1 1 . OPERATOR TRAINING (CREW A GROUND 
PERSONNEL) 


Table III-l Space Station Program Key Operations Functions 


11 Since it was impossible to provide a quantitative relationship among the program criteria , a hierarchy was established based on Task 
Force agreement that "A is more important than B, "etc. The criteria were further defined within the context of specific operations functions 
as the Panels proposed and evaluated options. 

,2 This presents a challenge to Space Station managers. The theoretical way to ensure safety is to develop extensive safety standards and 
operations constraints and to rigidly hold all Program operators and users to them. However , Program managers will face ever-present 
budgetary pressures, as well as the desires of users to "go where the research leads them" in real-time. Such pressures for operational 
flexibility must be tempered with sound management decisions regarding the waiving of these standards and constraints to fit individual 
situations. 
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cause undue conflict with previously selected payloads 
or partner interests. Finally, the Program will work 
with users to put them into the manifest. 

Payload Development and Integration: Payload 

development and integration includes definition, 
design, construction, and ground testing (functional 
verification) of the individual payload, integration of 
payloads to payload racks or Payload Interface 
Adapters (PIAs), and transport of the payload to the 
Space Station Program launch site(s). Program input 
will focus upon safety assurance and verification of 
rack-fco-Station and PIA-to-Stati on interfaces. (All 
other tasks are the responsibility of the user.) 

Payload Operations: Users can be expected to 

maintain ground control facilities for transmitting 
payload commands, receiving payload return data 
(telemetry), and for storing and analyzing data or 
products which are returned from the Station . 7 The 
capabilities of such User Operations Facilities (UOFs) 
shall be determined by the user community . 8 


Program Operations 

Space Station Program Operations are grouped into 
four subcategories: Utilization and Operations Plan- 
ning; User Integration; System Operations and User 
Operations Support; and Systems Engineering and 
Integration. 

Utilization and Operations Planning: Utilization and 
Operations Planning is the end-to-end process for 
developing requirements and schedules for Space 
Station operations. Users will submit their list of 
candidate payloads; it will then be the responsibility of 
the Program to translate the user requirements into a 
proposed manifest. System support planning will be 
performed by the SSP: resupply of consumables, 
systems operations and maintenance schedules, and 
crew assignment are typical of these continuous 
planning activities. This function also incorporates the 
sequencing of systems upgrades into the Program's 
flight and ground elements (e.g., coordinating addition 
of a new module with ongoing experiments and crew 
skills). Planning functions will be closely integrated 
with Space Transportation System and non-SSP 
information systems (e.g., TDRSS) planning functions. 

User Integration: User Integration is the process of 
assisting users in payload development. It includes 
any "user outreach" or "marketing" functions asso- 
ciated with encouraging prospective users to provide 


payloads; the assignment of a PAM to selected users ; 9 
engineering support to ensure that payload design 
conforms to Station configuration and safety 
specifications; and safety and interface testing and 
verification prior to launch and when the payload is 
installed on the Station. 

Systems Operations and User Operations Support: 
Systems Operations and User Operations Support 
include all of the activities undertaken by Program 
personnel to support space operations on both the 
manned base and the platforms . 10 This includes all of 
the ground-based activity devoted to maintaining the 
Station elements in orbit (such as crew activity 
scheduling, procedures development, trajectory analy- 
sis, crew training, data systems operations, prelaunch 
and postlanding processing and logistics operations), 
space operations (crew, Station system and payload 
operations on orbit) and sustaining engineering (M&O 
related) for operations support facilities. This function 
also includes configuration control of Station utiliza- 
tion and operations plans, as well as definition of crew 
training requirements. 

Systems Engineering and Integration: Systems 

Engineering and Integration (SE&I) encompasses the 
ongoing engineering analyses performed on hardware, 
software, and technical operations processes which are 
associated with sustaining the Station's space systems, 
their payload interfaces, and their interfacing ground 
systems (including information management systems) 
over the life of the Program. This includes the 
performance of technical feasibility studies, systems 
performance analyses, and production/operations costs 
trades relating to the proposed modifications as well as 
the preparation and dispensing of related engineering 
change requests. The SE&I function also includes the 
maintenance of Program configuration control for all 
baselined Station and interfacing ground support 
systems. 

Guidance for SE&I activities would come primarily 
from operations oversight functions (which provide 
long-term system objectives) and operations and 
utilization planning and user integration functions 
(which generate near-term system change require- 
ments). Feasibility and supportability analyses 
performed by the SE&I function would be used as 
inputs not only for engineering changes for ongoing 
operations, but also for advanced development efforts. 

III.A.2 Developing the Operations Framework 

The SSOTF deliberated at length over the development 
of an overall operations management and control 


7 Command links between the ground and the flight elements shall be managed by the Program. 

8 Some users may wish to develop highly proprietary User Operations Facilities (UOFs). Others may wish to share common overhead 
costs within a single facility; these could be centers oriented towards a specific area of investigation , referred to as "Discipline Operations 
Centers" (DOCs); or geographically -focused Regional Operations Centers (ROCs). All user facilities must be designed and operated in 
accordance with Program safety requirements. 

9 The Framework recommends the assignment of a single point of contact for each user. This SSP representative is the "Payload 
Accommodation Manager , "or "PAM. " 

l0 The SSOTF separated these functions for the manned base and platforms because of their different operational characteristics. 
Platforms will largely operate independently from the manned base. 
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and ground personnel need to be established and their 
performance monitored. Safety also dictates that the 
Program’s hardware systems and management 
structure incorporate "interlocks" which minimize and 
deter human and equipment error, alert operations 
managers when a malfunction has occurred, and 
minimize or isolate the effect of the error until it can be 
corrected. Finally, the Program operations structure 
must be capable of integrating outside safety reviews 
and oversight without causing undue burdens on 
ongoing system and user operations. 

Effective User Operations: Once the basic 

management and safety requirements of the Program 
are met, the next most important evaluation criterion 
is whether the Space Station is "user-friendly." This 
means that the Program should be managed as a 
facility for users, compatible with their modes of 
operation. While the complexity of space operations 
will continue to dictate stringent safety requirements 
in all phases of user and system operations, it is 
generally acknowledged that the Program’s "transpar- 
ency" to users can be improved as compared with past 
programs. It is important to note that user-friendliness 
is a requirement for program management as well: the 
sheer volume of users necessitates a reliable and 
efficient means for selecting, preparing and flying 
them . 13 

An option is considered superior in terms of user 
orientation if it has a well understood and "simple" 
process for proposing, developing, integrating and 
operating payloads. It must be acceptable to the entire 
range of expected users. ("Acceptable" is a relative 
term, since different classes of users will have different 
requirements.) Some of the specific measures used in 
applying this criterion were: level of user participation 
in payload selection and utilization planning, the 
length of time required to take a user from initial 
contact to on-orbit operations, the number of interface 
points between the user and the Program, documen- 
tation requirements, complexity of integration 
standards, and the level of available user autonomy in 
operations. 

Substantive International Participation: International 
participation as an evaluation criterion specifically 
addresses the desires of the partners to participate at 
all levels in the management and operation of the 
Program . 14 The SSOTF recognizes that specific roles 
and responsibilities have not yet been fully defined 
(this is the subject of ongoing negotiations); however, 
the Task Force noted that partners have an explicit 
desire to develop expertise in manned and unmanned 
space operations through their continuing involvement 
in the Program. 


Partner goals in the program are congruent, but not 
identical to, those of the United States. Specifically, 
the partners' desire to be given substantial operations 
responsibility through a decentralized management 
structure could, in some options, be in conflict with the 
safety and management effectiveness that comes from 
a "traditional" centralized NASA management 
structure. 

As well, the Space Station operations framework must 
be able to sustain changing partner sponsorship and 
involvement. A partner may drop out or alter its role 
in the Program, and new members may join. The 
management structure must be flexible enough to 
incorporate such changes without compromising safety 
or user operations. 

Assembly and Evolution: The operations framework 
must provide a smooth transition from the Station's 
deployment and assembly to "mature operations." 
While the assembly of the Station elements and 
deployment of platforms will transpire over a period of 
years, systems operations will commence with the 
deployment of the first elements, and user operations 
will grow as the Station resources to support them are 
put in place. Hence, the operations framework and 
organizational structure must support a smooth 
transition from assembly to mature operations. 

The Space Station's success will be measured not only 
by its ability to meet today’s missions, but by its ability 
to anticipate and accommodate tomorrow's. It is 
difficult at this point in time to predict which of the 
prospective users and user communities will drive 
Station utilization over time. As well, the technology 
which will be incorporated in the Station elements at 
deployment will certainly obsolesce as continued 
advances offer new or more efficient capabilities. The 
Station must be "organic," and have the flexibility to 
evolve to meet changing requirements and Program 
goals . 15 

From the operations perspective, this means having a 
configuration management and sustaining engineering 
capability to monitor current performance and conduct 
analyses of the benefits of prospective upgrades, and a 
planning system by which decisions to upgrade Station 
elements or systems can be made by the partners and 
then incorporated into ongoing operations. 

Operations Cost Effectiveness: The long term nature of 
the Space Station Program enjoins NASA and its 
partners to more carefully consider operations as a 
determinant of life cycle costs. Put in its simplest 
terms, three decades of running the Space Station will 
cost more than the ten-year development investment. 


13 Skylab was the most "Station-like" R&D mission flown to date. Skylab, however, was much more limited in scope and amount of 
operations: the Space Station will have a much more complex operations integration challenge across its diverse user spectrum. For 
example , life science researchers may desire special motion -inducing experiments at the same time that microgravity scientists will want to 
restrict motion on the Station. On the other hand, the Station will not need to have the activity -intensive timelines typical of Shuttle or 
Spacelab missions, since the Station isn't limited to a 7-10 day stay time. This implies that onboard activity scheduling can be performed 
with greater "margins "and flexibility in time sequencing. 

I4 The goals of the international partners as users of Space Station resources are contained in the preceding evaluation criterion. 

ls Most of NASA's previous experience base has been with well-defined missions which permit concurrent development of hardware and 
payloads , each optimized for the other. Since most mission lifetimes have been only a few years, designs could be "frozen" and little 
consideration given to upgrade once the payload has been launched. 
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Thus, the operations framework should recognize cost 
drivers, and attempt to streamline operations 
complexity and requirements wherever such actions 
would produce Program cost savings. 

However, the SSOTF strongly believed that cost, while 
an important consideration, should be a driver only in 
selecting among options which meet the fundamental 
workability, safety, user, partner and growth 
capability criteria. Stated another way, the SSOTF 
concluded that a less expensive option was not the most 
cost effective if it entailed unacceptable safety risk, 
adversely affected the productivity of users, or 
prohibited partners from realizing their long term 
Program objectives. 

In summary, the relationship of the Evaluation 
Criteria to the Program goals is depicted in the matrix 
in Table EEI-2. The evaluation criteria can have either 
a direct, indirect, or no correlation to a Program goal. 


For example, effective Program control indirectly 
supports most of the discovery and benefit Program 
goals. 16 There is a more direct correlation between 
effective Program control and the goals to reduce the 
costs of space operations. 17 Finally, Program control 
has an indirect correlation to promotion of 
international cooperation. 18 

Each option reviewed by the Task Force had to pass 
each of the criteria before it could be accepted as part of 
the Recommended Framework. (See the Preface for 
details of the SSOTF methodology.) Options were 
evaluated in relative terms: were they unacceptable in 
meeting the evaluation criteria; were they acceptable; 
or did they have features which made them especially 
advantageous? In comparing among options, the 
prioritized criteria provided the selection process. If 
two options were considered equal in terms of the most 
important criteria, the next most important criteria 
were compared, and so on, until one option "won out." 
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N/A 
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1 

D 

D 

N/A 

D 

1 
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D 

• 

• 
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D 
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1 
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D 

1 

1 
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N/A 

D 
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i 

N/A 

1 

D 

D 

D 
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D 
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1 

1 
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0 

FOREIGN 

POLICY 
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COOPERATION 

D 

N/A 

N/A 

D 

' 

N/A 


D » DIRECT CORRELATION 
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Table III-2 Relating Evaluation Criteria To Space Station Program Goals 


16 Effective Program control implies a management structure that will be adept at meeting user requirements and objectives, maximize 
allocation of resources, etc. It has no correlation to the goal of enhancing US. aerospace productivity as defined in Chapter II (enhancing 
that industry's productivity through participation in hardware development). 

17 A strong Program control framework will increase the ability of Program management to coordinate operations, maintain 
configuration control and commonality among subsystems, make proper tradeoffs in crew vs. ground personnel responsibilities, plan 
evolution, and take account of life cycle cost considerations. 

18 A good control structure enhances any given level of international cooperation by minimizing the chances for misunderstanding and 
by facilitating smooth operations, but does not bear a direct relationship on whether or not such cooperation should be pursued. 
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IILB. RECOMMENDED FRAMEWORK FOR 
OPERATIONS 

This section presents the Recommended Framework for 
operations as developed by the SSOTF. First, a short 
synopsis of the management and planning hierarchy is 
presented. The Recommended Frameworks for the 
manned base and unmanned platforms are then 
presented separately. 

IILB.L Introduction 

The central feature of the Recommended Framework is 
the provision of hierarchical utilization and operations 
planning and control: the process by which system and 
user requirements are identified, integrated into an 
operating plan, and implemented. Other functions are 
carried out largely to support this function. Hence, a 
description of the Framework centers largely on the 
end-to-end flow by which strategic objectives for Space 
Station utilization and operations are formulated and 
carried out at each management level. 

The SSOTF further detailed the operations functions 
presented in Figure III- 1 , and then hierarchically 
grouped the resultant subfunctions into three basic 
levels of management and control: Program Policy 
(’’strategic"). Program Integration ("tactical") and 
Program Execution (real-time operations). 19 This 
management hierarchy exercises control over four 
levels of planning, each of which has one or more major 
planning products associated with it. The four 
planning levels are: Strategic Utilization and 
Operations Planning (five-year planning horizon); 
Tactical Utilization and Operations Planning (two- 
year planning horizon); Increment Planning 
(development of detailed planning and scheduling data 
for an increment specific timeframe); and Increment 
Execution Planning (development of execute level 
plans and procedures to perform increment operations 
in real- time). The Program Integration (tactical) level 
of management controls both the Tactical Utilization 
and Operations Planning and Increment Planning 


functions. This hierarchy, and the major planning 
products associated with each management level are 
presented in Figure HI-2. 20 


Program Policy 

Program Policy functions establish and coordinate the 
strategic objectives of the Program for users and 
system operators. The Strategic Utilization and 
Operations Planning function develops the long term 
plan for Station operations. The major product 
developed at this level is the Consolidated Utilization 
Plan (CUP). The CUP is the basic reference document 
for Station operations and utilization, and covers a 
five-year planning horizon. It is a "document of intent" 
which lists all of the payloads which the Program 
(NASA and its partners) would like to fly. 21 The CUP 
normally will be updated on an annual basis. 22 

The CUP is approved by the Multilateral Control 
Board (MCB). The MCB will comprise senior 
representatives of all Program partners, and will be 
chaired by the NASA Associate Administrator respon- 
sible for Space Station operations. Station system 
requirements will be developed by an international 
Systems Operations Panel (SOP). User requirements 
will be collated by an international User Operations 
Panel (UOP) and integrated with system requirements 
to form the CUP. 23 

Program Integration 

Program Integration functions implement objectives 
and policies produced at the Program Policy level 
through the development and management of more 
detailed plans and directives. The content of the 
functions becomes progressively more "technical" as 
the function moves from a "pure policy" content 
towards end products for Program Execution. Program 
integration functions are accomplished in two steps: 
the development of overview increment manifests 
through a two-year tactical utilization and operations 


19 Many times , a single function (such as utilization and operations planning), will extend through all levels of management, while other 
functions (such as systems operations and user operations support) are generally associated with a single management level (Program 
Execution in this case). Hence, many functions will be performed simultaneously at multiple levels of management , and in multiple 
organizations within a single level of management. A complete regrouping of operations functions by level of management responsibility is 
presented in Appendix B of this report. 

*°The control and product flow which follows is presented in a "top-down" fashion. Each level of activity develops a "product” which is 
used at the next tower level as guidance for its activity. This process continues until the "end product" (i.e., execution of operations) occurs. 
While it is not discussed in detail here, the hierarchy also has a reciprocal feedback path. Completion of execution operations is documented 
and passed upwards as a "product," which is used as input at the next higher level for development of an operations review product , and so 
on. In this way planners at the top of the hierarchy provide direction to "doers" at the bottom, who in turn produce the information which 
allows those at the top to gauge the efficiency of the Program in meeting goals. 

2i Program Integration level manifest assignments can only be made following more detailed analyses of payload interfaces with the 
various operational aspects of the Program, as well as with other payloads selected to fly in the same time period. 

23 The Task Force believed that an annual review would be sufficient, but many noted that extraordinary circumstances (either in 
response to unexpected Program contingencies or opportunities) might dictate ad hoc or more frequent strategic utilization and operations 
planning requirements. Conversely, it was also recognized that the process may not be necessary on an annual basis if utilization and 
operations requirements are "stable. " 

23 Inputs to the UOP are provided by the partner Space Station User Boards (SSUBs) which are managed by the user communities of 
each partner. The SSUBs provide utilization resource projections and requirements by user group to the UOP for integration with the 
systems requirements in the CUP for final approval by the MCB. (See Section IILB. 2 and the User Development and Integration Panel 
report for a further description of the SSUB function.) The U OP will be chaired by the Program Integration level NASA Program Scientist. 
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Figure III-2 Recommended Framework 
Planning And Control Hierarchy 


planning process, and the development of detailed 
increment objectives through a flight increment 
planning process. Program Integration level functions 
require personnel who can bridge both worlds: who 
have a "global view" of the Program’s objectives and a 
technical understanding of the capabilities and 
limitations of the Program elements and control 
structure . 24 

The key product of the tactical utilization and 
operations planning process is the Tactical Operations 
Plan (TOP). The TOP assigns system maintenance and 
operations activities and user payloads contained in 
the CUP to specific flight increments . 25 The TOP will 
be approved by the internationally staffed Program 
Operations Control Board (or POCB, again chaired by 
NASA), and developed by "utilization" and "system" 
control panels (UCP and SCP). User input will come 
from the CUP, with more detailed requirements 
provided to the Utilization Control Panel by the Space 
Station Users Working Group (SSUWG). 


The Flight Increment Plan (FIP) contains the 
information required by the operations execution team 
to perform execution level planning for a specified 
flight increment. FIPs will be developed by an 
Increment Change Management Team. Each 
increment will have an Increment Change Manager 
who coordinates the required planning and analysis 
activities. Investigators Working Groups (IWGs), 
comprised of the users selected for each increment (or 
their discipline representatives), will work closely with 
the Increment Change Managers in developing 
schedules. The POCB will have responsibility for 
ensuring that sequential FIPs are compatible, and all 
Increment Change Managers will report through the 
POQB. 


Program Safety Review Boards reside at the Program 
Integration level, and exercise oversight at all levels of 
management and operations. These review boards will 


24 Program Integration planning activities are subdivided into " tactical operations " (integrated planning activities with a 2-year 
planning horizon) and '< increment operations ”( activities associated with planning a specific flight increment). 

2S Since the SSOTF assumed an average of eight STS flights per year (an average of one every 45 days), the TOP would include 16 flight 
increments . The TOP will include overview data generated in the Flight Increment Plans; however , the FIPs are much more detailed 
documents and are "stand-alone” products. 
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be staffed by the Program, but chairmen will be 
supplied by the independent Headquarters SRM&QA 
organization. 

The Task Force recommends that Program Policy and 
Program Integration functions should be the 
responsibility of the Space Station organization at 
NASA Headquarters. This would provide a focal point 
for Agency roles and mission policy, a single interface 
for international negotiations, and a means of 
coordinating multiple operations and engineering 
support centers. It also provides a high level interface 
to NASA's other program organizations. 


Program Execution 

Program Execution level functions result in 
institutional end products (e.g., detailed onboard 
timelines and procedures for a period of operations), 


and the actual implementation of the details of a plan 
in support of a specific end product (e.g., ground 
personnel performance of a system test and verification 
check). These functions will be distributed to the 
relevant operations centers or "centers of expertise." A 
summary flow of the program control documentation is 
presented in Figure HI-3. 

Increment Execution Planning entails detailed 
planning and production of operations and utilization 
execution plans, and real-time replanning of operations 
in response to contingencies or new opportunities. 
Execute level products include the plans, procedures 
and constraints required by the operations support 
centers' ground personnel as well as the onboard crew 
for performance of daily duties and assigned tasks. 26 
Execution functions include ground prelaunch and 
postlanding equipment processing, crew training and 
in-flight operations, monitoring and control of Station 
elements and their payloads, sustaining engineering 
analyses which support real-time operations, and the 
operation of the ground support network. 
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UTILIZATION 
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TACTICAL 
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FLIGHT 

INCREMENT 
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Figure III-3 SSOTF Operations Framework 
Program Control Documentation Hierarchy 


3€ Execution plans and data developed at this planning level include the Increment Operations Plan (IOP) t Flight Data File (FDF) f 
Increment Hazard Control Plan (IHCP), Flight Rules, Reconfiguration Data and other real-time execution plans and supporting 
documentation derived from the FIP. 
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Responsibility for execution operations will be vested 
at the assigned NASA centers and international 
partner sites. The SSOTF assumed that these various 
NASA field center and international partner imple- 
menting organizations would define the necessary 
preflight and real-time control mechanisms required to 
implement their assigned Station responsibilities. 
Figure III-4 provides a summary of the control 
mechanisms proposed for all the management levels of 
the Recommended Framework, and their interactions 
with the Program planning process. 

III.B.2. Manned Base Operations Framework 

The Task Force recommends managing multiple 
elements of the manned base as an integrated facility 
rather than as a collection of autonomous elements. 27 
This funda-mental characteristic is driven by the 
Program’s complexity in both systems and user 
operations. The extra layers of management 
coordination needed to maintain the facilities and 
operations under separate organizations would impede 
efficient manned base operations. Operations safety on 


the manned base would also be more difficult to achieve 
if operations across elements were not coordinated in 
planning and execution. From the user perspective, 
separately managed elements would greatly 
complicate pre-flight and flight activities. User 
interfaces would be much more complex; the number of 
steps for selecting, manifesting and integrating users 
would multiply, adding unnecessary requirements on 
them. Onboard activities would also lose flexibility, as 
real-time replanning of user operations would become 
much more cumbersome. 28 

The Task Force also recommends that NASA assume 
the lead role in manned base management and 
operations. The Task Force believes that this is a 
logical approach, based on NASA’s significantly larger 
contribution to the Program and its more extensive 
manned systems operations experience. In the 
Recommended Framework, planning and control of 
operations will be focused in the NASA Space Station 
operations organization; NASA will chair the manage- 
ment control boards governing Station operations at 
the strategic and tactical levels. NASA will also retain 
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Figure III-4 Program Control Summary 


27 This is in contrast to operations of multiple platforms which are planned and performed with a high degree of individual 
" element” autonomy . 

28 The dictates of limited common resources, and the unavoidable propagation of physical conditions from one element to another, 
require manned base schedules and manifests to be carefully balanced; the development of several "mini -manifests " would make it difficult 
to respond to a user replanning request in one element which might affect several separate timelines. A centralized operations management 
structure with a "system-wide "view would be in a better position to make tradeoffs and conduct replanning activities. 
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overall responsibility for manned base and crew safety. 
International partners will participate in all levels of 
the operations planning and management structure on 
an integrated basis. 

The Task Force assumes that users will opt to conduct 
their planning activities in a "distributed" manner (at 
geographically dispersed sites or in demographically 
diverse groups). User planning activities are brought 
together at the Program Policy level by the interna- 
tional Multilateral Control Board. At the Program 
Integration level, user activities are conducted by user 
working groups and supported by Station accommo- 
dation offices, while at the Program Execution level 
user activities are coordinated by a payload operations 
integration function. 


A typical day's activity for the manned base will be 
analogous to the operation of a multifunctional 
research and development complex on Earth. The 
range of Station operations activities for the manned 
base are depicted in Figure III-5. These include: 


operations and utilization planning (determining who 
uses the Station for what purposes); logistics opera- 
tions support (activities associated with preparing men 
and material for transport to and from the manned 
base); space operations (activities which transpire 
onboard the Station); and space operations support 
(ground-based activities which help maintain the 
integrity of the manned base assets in orbit). 

III.B.2.a. Strategic Utilization and Operations 
Planning 

The basic purpose of Strategic Utilization and 
Operations Planning is to allocate Station resources to 
systems and user requirements. 29 Figure EI3-6 depicts 
the planning process for development of the Consoli- 
dated Utilization Plan. This activity will transpire at 
NASA Headquarters. 

The MCB will have approval authority for this 
function, with the primary product at this level being 
the Consolidated Utilization Plan (CUP). The strategic 
planning function will have three primary sources of 



Figure III-5 Manned Base Operations Infrastructure 


29 Systems allocations include resources required to maintain the existing elements on orbit , and to incorporate upgrades , block changes 
or additions to them. Utilization allocations include assignments on the basis of partner and user groups, and the selection and 
prioritization of individual payloads. 
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Figure III-6 Manned Base Operations Framework 
Strategic Planning 


input: broad policy and objectives provided through 
international memoranda of understanding (MOUs) 
and in-place policy statements (with periodic updates 
as required); systems operations requirements 
collected by the SOP (including transportation needs, 
data systems requirements and actual manned base 
systems performance data); and projected payload 
requirements collected by the UOP from the user 
community (including actual payload performance 
data). 

The Systems Operations Panel will develop strategic 
requirements for operation and maintenance of 
manned base elements. 30 The SOP will also provide for 
analysis of Space Station evolution objectives and 
planning, based on analyses of user requirements (i.e., 
demands for more or new resources) and input from 
partner and outside technology development efforts. 
The SOP will work closely with the transportation 
systems and space data systems operations 
organizations for projections of transportation and data 
systems availability as inputs to the planning process. 


International MOUs, and other Program policy 
documents will provide the basic guidance for 
allocation of utilization resources. While resources will 
be assigned to Station elements, "ownership" of those 
resources will be held by the Program partners as 
determined by MOU, to be assigned by partner 
SSUBs. 31 Each partner’s SSUB establishes schedule 
and discipline priorities for its respective users along 
with specific requirements to be accommodated by the 
manned base (or one of the platforms). These priorities 
and requirements are submitted to the Program 
through the UOP. The UOP and SOP jointly coordi- 
nate Program analyses of these user requirements 
against Station systems resource capabilities and 
transportation system(s) availability. Resulting 
guidelines are published annually in the CUP for use 
by the Program Integration level organizations in 
manifesting payloads to specific flight increments. (See 
Figure EH-7.) 

The SSOTF recommends that the NASA SSUB allocate 
"blocks" of resources to the major user sponsors. These 


30 A$ the MCB’s "agent” for strategic systems planning, the SOP is concerned with planning for those space systems maintenance 
requirements or technology upgrades to the manned base and platforms which will have a significant impact (brief or long term) to overall 
Program resource availability and/or utilization. Routine maintenance activities are planned and scheduled at the Program Integration 
and Program Execution levels of the Program. 

31 The allocation formula will most likely be based on some relation of development and operations costs supported by each partner. 
Since it is assumed that NASA will bear the majority of development and operations costs , a significant portion of resources allocated to the 
JEM and Columbus modules will be reserved for U S. users. 
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Figure III-7 User Role- Strategic Planning 


groups include the NASA user codes and other 
government agencies. 32 The sponsors would be 
represented on the SSUB by a NASA Associate Admin- 
istrator, or his equivalent for the non-NASA users. 
Partners can structure their SSUBs to meet their 
specific requirements. 

Each sponsor would then select candidate payloads 
through an internal review process. The Station 
Program will support the user selection process by 
conducting feasibility studies to determine the 
Program’s ability to support the various candidate 
payloads, and through provision of general marketing 
support to inform users of the Station's capabilities. 


Sponsors would submit their candidates to the User 
Boards for approval, prioritization, and recommen- 
dation for flight scheduling. Each SSUB would then 
submit its annual "block" of prioritized users to the 
UOP, which would develop a draft integrated user 
plan. This plan would then be integrated with system 
requirements provided by the SOP to result in the 
development of a draft CUP. The Consolidated 
Utilization Plan will be published annually following 
MCB approval (or more frequently as required). 
Resources which would be allocated in the CUP are 
listed in Table HI-3. A typical CUP overview for the 
year 1995 is presented in Table Ed-4. 



III.B.2.b. Tactical Utilization and Operations 
Planning 

The goal of the integrated tactical planning process is 
the development of a two-year manifest for manned 
base utilization and operations. The Program 
Operations Control Board (POCB), located at NASA 


Headquarters, will have approval responsibility for 
this function. Like the MCB, the POCB will be chaired 
by NASA, and staffed by NASA and its partners. The 
sources of user input for the POCB include the 
Consolidated Utilization Plan, and detailed payload 
data from the Space Station Users Working Group (as 
coordinated by the SSUWG Steering Committee), and 


32 The Office of Space Science and Applications would sponsor traditional Code E science activities ; the Office of Aeronautics and Space 
Technology (Codie R) would sponsor technology development users. Academic users would be sponsored by the NASA office most 
appropriate to their particular activity. The Office of Commercial Programs (Code I) would sponsor all commercial activities which 
involved cooperative agreements between NASA and industry. The Office of Space Station would sponsor reimbursable commercial 
payloads. Other U.S. government usage (e.g., DOD and NOAA) and reimbursable non-partner foreign payloads would represent 
themselves. User outreach and marketing support is shared by the user sponsors and the Station Program. The Program will be 
responsible for providing general marketing information on Station systems and capabilities to support the user sponsors, and will also 
have the direct responsibility for marketing commercial reimbursable users (or other reimbursable users which approach the Program for 
information). 
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ON-ORBIT RESOURCES TO BE ALLOCATED AND MANAGED 


Crew Time (IVA, EVA) 

Power 

Payload Rack Space 
Microgravity Environment 
Command/Data Flow 
General Storage (trash, food, ORUs, etc.) 
ECLSS Capabilities and Consumables 
Thermal Control 
Clear Pointing Arcs 
Station Reboost Consumables 
Flight Telerobotics System 
External Servicing Facility 
OMV 

Up and Down Mass 
External Payload Attach Points 


Table III-3 Resources Allocated In The Consolidated Utilization Plan 



ASSUMPTIONS: 1 . 5-YEAR PROJECTION OF INTERNATIONAL SPACE SYSTEM & USER SYSTEM MANNED BASE AND PLATFORMS OPS 

2. SEPARATE MANNED BASE AND PLATFORM SECTIONS 

3. UPDATED ANNUALLY BY SOP AND UOP AT END OF PREVIOUS OUTYEAR; APPROVED BY MCB 


Table III-4 Consolidated Utilization Plan Contents Overview 


ORIGINAL PAGE 
COLOR PHOTOGRAPH. 








requirements databases. Systems inputs will be drawn 
from the operations and development centers, and the 
launch operations organizations. 

The primary product at this level is the two-year 
Tactical Operations Plan (TOP). The TOP is 
essentially a compilation of key planning data 
regarding transfer operations, 33 payload operations, 
element systems operations, onboard crew operations 
and related training, logistics operations, and 
transportation systems requirements. This data is 
scheduled on an increment-by-increment basis for a 
two-year period. The process for developing a Tactical 
Operations Plan is presented in Figure DI-8 and an 
overview of the contents of a TOP is presented in Table 
m-5. 

When considering the step-by-step process of 
developing a TOP, it is important to recognize that it is 
a constantly changing document. The TOP is 
published on an increment-by-increment basis. Hence, 
it is updated with the initiation of each flight 
increment on orbit, and the "entrance" of a new 
increment at the end of the TOP coverage period. As 
well, individual increments within the TOP evolve as 
they move through the queue. Additions are made as 
user and system payload requirements are refined, or 
in response to new empirical data on systems and 
payload requirements, in-flight changes or failures of 
either Station systems or user payloads, transportation 
capabilities, and other increment planning inputs. 

The POCB's Systems Control Panel (SCP) fulfills an 
analogous role to the MCB's Systems Operations Panel. 
The SCP is responsible for determining system 
resource requirements across the two-year TOP 
horizon. The SCP will draw on the resources of the 
manned base increment planning and operations 
execution organizations: the Space Station Support 
Center for space operations, sustaining engineering, 
and crew training and operations; the Logistics 
Operations Center for logistics operations support, and 
pre and post- flight operations support from the launch 
site processing organization (including actual outputs 
from the Space Station Processing Facility). The SCP 
must also work directly with the transportation 
systems operations organization(s) and the data 
systems operations organization(s) for their respective 
support analyses. 34 

The Utilization Control Panel (UCP) operates 
analogously to the User Operations Panel at the 
strategic level: it is the coordinating body which 
integrates user community requirements for Program 
Integration level planning. Primary user inputs to the 
UCP include the Consolidated Utilization Plan, the 
Space Station Users Working Group and Investigators 


Working Groups (IWGs) for each increment, the 
Mission Requirements Database, the Payload Accom- 
modation Managers, and actual payload operations 
data from the POIC. Modifications to individual 
increments will be developed and proposed by 
Increment Change Management Teams. (See below.) 

The UCP's draft manifests will be sent to the SCP for 
integration with manned base system, transportation 
system and data system requirements. The draft TOP 
is reviewed by the responsible operations organizations 
before it is finalized and approved by the POCB. New 
increment manifests contained in the TOP serve as the 
departure point for more detailed Increment Planning 
and Increment Execute Planning activities. The 
Strategic and Tactical Utilization and Operations 
Planning flow is summarized in Figure III-9. 


III.B.2.C. Increment Planning 

Increment planning is the next step in the planning 
process: the development of increment-specific data 
which in turn is used to produce detailed resource 
utilization schedules, activity templates, procedures 
and operations support data in advance of the final 
processing, launch and integration of payloads and 
transfer of crew. This function is coordinated at NASA 
Headquarters, with support as required from the 
responsible field center operations organizations 
(including partner organizations). 

Increment manifests approved in the TOP must be 
amplified so as to provide specific directives for 
operations execution planning organizations. Payloads 
selected in the CUP and manifested in the TOP must be 
defined in terms of resource requirements for a specific 
increment (e.g., mass, volume, and logistics support 
parameters). Resource parameters for payloads which 
will be integrated into the manned base prior to the 
commencement of the increment must be updated and 
modified as projections or actual experience warrant. 
Likewise, updated Station overhead requirements, 
consumables projections, maintenance, and common 
systems capabilities must be detailed for the specific 
increment. Table HI-6 illustrates the range of typical 
contents of the FTP. 

The process for developing a Flight Increment Plan is 
depicted in Figure ELL 10. Each increment is assigned a 
dedicated Increment Management Team (IMT), headed 
by an Increment Change Manager. The team consists 
of the personnel listed in Figure HI-10 under Space 
Operations, Integrated Logistics Operations, Data 
Systems Operations and Transportation Systems 
Operations. 35 


53 Transfer operations include those activities associated with the transfer and set-up of payloads from the STS or ELVs into the manned 
base. Transfer operations begin prior to STS arrival (systems housekeeping and preparation of equipment for return to Earth ) and extend 
through STS departure and subsequent installation (and checkout , if immediately required) of the newly delivered equipment. 

34 Interaction with the transportation operations organization is required to develop STS or ELV manifests, and to coordinate payload- 
to-transportation system interface analyses. Coordination with the data systems organization will enable the Program to account for 
changes in data support capability (e.g., a change due to initiation, modification or termination of a non-Space Station program). 

35 At first, the team consists only of "core" members associated with planning the details of the increment at that time (including 
representatives from the transportation and data systems organizations). As the increment draws nearer, the team is expanded to include 
the support personnel who will actually execute the Increment Plans. The evolution of the Increment Management Teams is analogous to the 
way in which the Mission Control Center (MCC) flight control teams evolve as an STS flight draws nearer. 
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Figure III-8 Manned Base Operations Framework 
Integrated Tactical Planning 
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Figure III-9 Strategic And Tactical Planning Process Flow 
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KBY MTUMBS Of THE TACTKAL OPERATIONS PLAN 

• The CUP is tiw primary source document used in TOP development 

♦ The manned best TOP is the "to#* heel planning document pertaining to specific increment utilization end operations. 

♦ The TOP is a pro&ct of and is controlhd by the Program Integration level of operations management 

• The TOP'S principal function h to serve as an increment requirements or "manifest" document which defines key utilization and 
operations planning elements (payloads, CPUs, growth systems, etc) and Program mi l esto n es associated with each inc rem ent 
over the next two-year period Of manned base operations. 


• User inputs supporting TOP de velop ment are provided through the various Payl o ad Acco mm od at io n 


(PAMs). (See 


• The TOP highlights logistics, transportation systems, and communication and data services requirements as a key determinant in 
manned base manifesting and operations capability. 

e The TOP provide* the required data to enable increasingly detailed planning for specific incremen t activities to be perf o rmed by 


Program Integration and Program Execution level personnel. 

Inputs to the TOP include: 

GomoHdatadlMEizationPteo .v 


Tworyeardevehpmert schedules 
User operations support a nalyses 

- Sustainmgenginee fin g ass e ssm en t s 
• System mai nte n a nce schedules 

- Engineering change requests 

- Safety assessments 

Training end simulation facility requirements 

- Crew utilization policy 
Accounting and control guidelines 
Transportation operations schedules 
Date Systems operations schedules 

TOP data typicatty might indude: v ; 

- Tyvo-year operations schedule* by increment 
iwo-year ovenncwof paytoaos oy tncremenx 
Trajectory management slate 


Systems configuration and operations protocol changes by increment 


THBROLB OP THE PAYLOAD ACCOMMODATIONS MANAGE* (PAM) 

APayload Accommodation Manager is espgned to each user selected under the CUP for participation in the ESP. The RAM's primary 
responsibility is to serve as the user** advocate to the Program, end to facilitate the user 9 * interactions with ati operational aspects of 
the Program. The PAM will be assigned upon initial acceptance of the user and provide support through post-flight acqu isition ofatt 
required data and hardware. Each PAM will haw the responsibility for coordinating the completion of required payload integration 
documentation (e.g., Payload Integration Plan) with a s s igned users. PAMs will be provided by NASA and eech international partner, 
and will generally have a utilization-oriented background. 


TACTICAL UTILIZATION AMD OPERATE nmmfm SUBFUNCTIONS 

Within the Tactical Utilization and Operations Planning function stpep hpmber of iterative subfunctions whkh are required to 

develop increment assignments. (Reference Figure 111-8.) The tactkai operations planning function must balance these lo develop 

the TOP: \ [.% r 

• Umr Support Pinning: Provid'd by the UtHizttion Control PobkfUCP). this function develops current and future user 

requirements for integration into the TOP. 4 * , 

• Transportation and Logistics Resource Planning: Provided by the importation systems organizations and tha Program 9 * 
Logistics Operations Center, these organizations develop transpe^ation and logistics support requirements, arrange for 
transportation, and determine ground support capability constraints. 

• Systems Operations and Maintenance Pfenning: Provided by the Systems Control Panel (SCP), these functions develop 
incremental integrated manned base systems maintenance requirements, provisioning requirements, manned base resource 
availabilities, and optional manned base enhancement requirements. 

• Safety Planning: Developed by the Program and reviewed and approved by independent safety review panels, this function 
establishes safety control procedures, plans and guidelines for inclusion in the TOP, and oversees development of safety 
requirements. 
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Table III-6 Flight Increment Plan: Increment - Specific Data (Typical) (Continued) 










UNIQUE STS CREW REQUIREMENTS 
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Table III-6 Flight Increment Plan: Increment - Specific Data (Typical) (Continued) 
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2 YEAR TOP - FLIGHT INCREMENT REQUIREMENTS 

1 . LOGISTICS - UP/DOWN MASS 

2. PAYLOADS AND ALLOCATED RESOURCE ENVELOPES 

3. TRANSPORTATION MANIFESTS 

4. CREW SKILLS 
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PROGRAM 
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CONTROL BOARD 
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5. PROGRAM SCIENTIST 
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OUTPUT: 
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PLANNING AND 
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I 
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AND SUPPORT 


SPACE OPERATIONS 

E IGRATED LOGISTICS OPS 


Figure III- 10 Manned Base Operations Framework 
Increment Planning 


The IMT process for developing the FIP follows the 
CUP and TOP methodology: systems support 

requirements are first allocated from total available 
resources; the remaining resources are then allocated 
to specific payloads according to TOP guidelines. IMT 
members represent the various aspects of operations at 
the Program Integration and Program Execution 
levels. Each member serves as liaison between the 
IMT and the areas of operational expertise that 
member represents. Thus, institutional resources are 
available for conducting detailed technical analyses on 
space systems and payload systems hardware and 
software (or on purely operational considerations such 
as flight techniques) as necessary to facilitate an 
effective overall plan for integrated increment 
operations. 

Planning for user activities associated with each 
increment is developed by the POIC consistent with the 
TOP and guidelines developed through the Investiga- 
tors Working Group (IWG). The IWG is composed of 


those users (or their sponsors) represented on the 
specific flight increment. (I.e., there is a corresponding 
IWG for each increment.) The IWG and the PAMs 
insure that user interests are maintained in the 
increment planning process. 


The draft FIP will be reviewed and approved by the 
various operations organizations. These organizations 
will verify increment-to-increment compatibility, as 
well as direct the independent safety reviews. Upon 
approval of the FIP, the SE&I office at NASA 
Headquarters will arrange procurement of transporta- 
tion and data systems capability, and development of 
logistics support plans by the Space Transportation 
Systems, Data Systems Operations and Logistics 
Resource planning functions. Once the FIP is 
approved, the Increment Change Manager is responsi- 
ble for ensuring that the execute planning and 
implementation tasks on the "critical path" are 
completed on schedule. 36 


36 The Increment Change Manager has the authority to redirect the efforts of the various institutional support functions in the interest of 
accomplishing the requisite activities for an on-time launch and start of the onboard flight activities. 
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KEY FEATURES OF INCREMENT PLANNUE6 

The primary emphasis of Increment Planning is on Program Integration level planning for ground and onboard configuration and 
operations changes to be implemented during each increment 

Increment msnegement is centralized at the Program Integration level with actual performance of many planning support 
functions distributed to the implementing operations centers or partner sites. 

The Increment Change Manager leads this process and with supporting IMT members, formulates and integrates operations 
policies and preparations across the Program for all configuration and operations changes which affect the assigned increment 
Each increments Flight Increment Plan (FIP) will contain increment-specific operations information pertaining to the preparation 
for and execution of manned base activities during that increment, and will serve as a "template* authorizing overall ground and 
onboard personnel and equipment resource utilization. 

Although planning for each Right increment at the FIP level is a separately managed activity, it must be dosety coordinated with 
subsequent Increment Change Managers as well as with Program Execution level personnel engaged in scheduling and executing 
the current increment's orbital activities. 

Users are represented by their Payload Accommodation Manager (PAM) for all increment activities. (I.e., no separate user 
integration process is requited for transportation systems support). 

The Increment Planning process continues through handover to the Program Execution level personnel for detailed increment 
execute planning and data preparation and implementation. 

During periods of increment execution, the Increment Change Manager serves as a consultant to the SSSC Flight Director and 
POIC Payload Operations Director as required to effectively replan operations activities in real-time 
Inputs to the FIP indude: 

- Payload manifest 
Payload/systems resource allocations 
Crew skill requirements 

Manned base maintenance requirements 

- Payload servicing requirements 

• Equipment processing requirements 
Platform servicing requirements 
Launch vehicle manifest 

- Logistics plans . 

Uniquedata system requirements 

- Unique STS crew requirements 

Onboard and ground system Right initialization data 
Draft payload operations schedules 

- Cargo processing requirements 

- Crew training requirements 
FlPdata typically might indude: 

- Critical path schedules 

- Manifested payload priorities A key sequences 

- Systems A payloads resource allocations 
Crew skill requirements summary 

- Servicing A maintenance requirements 
Up/down transportation system manifests 
Transportation system schedule A performance 

Ground A onboard hardware A software upgrade! reconfiguration data 


INCREMENT TEAM ROLES 


The Increment Management Teams draw on the support of the following members during the increment planning process: 
e Manned Base and STS Flight Directors (FDs): Provide an integrated set of Station and STS space systems operations and 
maintenance requirements and priorities; safety concerns; integrated systems and user requirements; and crew training 
requirements and schedules. 

a Payload Operations Director (POD): Prxwides an integrated set of use^ operations and servicing requirements and priorities 
e Payload Accommodation Manager (PAM): Coordinates Indhrldualusmwensportation , operations end servicing requirements, 
e Station and STS Crews: Provide expertise on manned base systems ted crew capabilities and knowledge of user objectives, 
e Program Scientist (PS): Provides science community gosh and priorities** well as utilization advice. 

e Sustaining Eng in e eri ng Manager: Provides current space systems performance status; scheduled maintenance expertise; 

resource allocation methodology; and an integrated set of transportation sy^em accommodations, 
a Station Launch Site Support Manager, STS Launch Site Flow Manapet and key processing team representatives; Provide an 
integrated set of prelaunch and postlanding processing operation*, maintenance and servicing requirements; schedule 
requirements; and STS cargo handover requirements. 

e Logistics Support Manager: Provides an integrated set of hgistks support requirements and the logistics management plan, 
e Network Director (ND) and key data system team representatives: Provide NASA space and ground network status and 
capabilities (TDRSS Space Network, Ground Network, and NASA Communications Network); and special data handling 
requirements. 

e STS Payload Integration Manager (PIM): Provides STS requirements for Station logistics carrier hardware, 
a STS Flight Integration Manager (FIM): Provides STS manifest Integration requirements. 
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III.B.2.d. Increment Execute Planning 

Increment Execute Planning is a Program Execution 
level function encompassing the development of 
execute plans and procedures which enable crew and 
ground support personnel to perform increment 
operations in real-time. This includes the detailed 
planning of operations and utilization execution plans 
(in particular the Increment Operations Plan-IOP) 37 , 
and real-time replanning of operations in response to 
contingencies or new opportunities. Execution plans, 
procedures, schedules and related data are derived 
from the relevant FIP and developed at this planning 
level by the responsible operations support centers. 

The Increment Execute Planning process directly sup- 
ports the continued "maintenance" of the parent FIP. 
For example, as the detailed planning process evolves 
and the impacts of integration of manifested user and 
manned base systems activities becomes more 
apparent, it may become necessary to redirect certain 


systems or payload activities, either in priority or order 
of accomplishment or, in extreme cases, to reassign 
them to another increment. Thus, an effective incre- 
ment planning process is a continuum involving the 
IMT as well as the increment execute planning team. 

Figure III- 1 1 provides an illustration of the 
interrelated nature of the Increment Planning, 
Increment Execute Planning and Real-time Operations 
functions. At this level, distinctions between Program 
Integration and Execution level activities become 
blurred as the degree of functional overlapping 
increases (especially for payloads which remain on 
orbit for multiple increments or for maintenance and 
servicing tasks which bridge increments). The 
centralized management aspects of the Recommended 
Framework strengthen the smooth flow of plans and 
information between the management levels of the 
Program, while the distributed execution planning 
aspects allow flexibility to support independent user 
operations planning. 


KEY FEATURES OF INCREMENT EXECUTE PLANNING 

Execute Plans and Data: Following the inclusion of an increment in the TOP and the subsequent development of that increment's FIP 
by the Increment Management Team , the execute teams at the various support centers begin preparation of the multitude of ground 
support and flight products which are derived from the source FIP and are required to actually implement the increment operations. 
Execute plans and data provide technical direction in preparation for and implementation of real-time support to onboard 
operations involving space systems and payload activities. These data support nominal and contingency operations and typically 
include such items as: an Increment Operations Plan (tOP) which provides the crew with detailed timelines for the transfer operations 
period of the increment; an Increment Hazard Control Plan (IHCP) which identifies systems and payload operations which require 
special operations precautions during preparation and/or operation; detailed schedules which trace the flow of hardware through 
the SSPF in preparation for flight; manifests of equipment to be taken to and from the Station elements using the appropriate 
transportation system; increment-specific crew training plans; and the Flight Data File (FDF) complement of procedures and data 
developed and verified to support execution of systems and payload operations onboard the manned base. Most execute plans and 
data will reside in electronic data bases and will be available to each U.5. and partner support center. 

• Management of Increment Execute Planning is distributed at the Program Execution level with actual performance of detailed 
planning support functions the responsibility of the implementing operations centers or partner sites. 

• Inputs to the increment execute planning process provided by the FIP typically include: 

Critical path schedules 

Manifested payload priorities A key sequences 
Systems A payloads resource allocation data 
Crew skill requirements summary 
Servicing A maintenance requirements 
Up/down transportation system manifests 
Transportation system schedule A performance data 
Ground A onboard hardware A software upgrade/ reconfiguration data 
e Increment execute products typically include: 

Space operations: 

Increment operations Plan (lOP-approximately two weeks of detailed planning involving transfer operations associated with 
STS or ELV resupply missions) 

Space Systems operations and Maintenance Procedures 
Payload operations Procedures (user supplied) 

- Payload Servicing Procedures ( NASA supplied) 

Supporting Data , Maps , Charts , etc. 

Space Operations Support: 

Support Center Hardware A Software Reconfiguration Schedules A Data 

- Increment Hazard Control Plan 
Mission Rules 

Console Handbooks A Ground operator Procedures 

- Personnel Support Plans A Schedules 

- SSSC Interface Protocols 

Transportation A Data Systems Interface Protocols 

- Onboard Data Configuration Control Methodology 

- Increment Specific Crew Training Plans 
Onboard Anomaly Logs 

- Space Systems Maintenance Procedures 
Space Systems Sustaining Engineering Data 


S7 The IOP provides detailed 
manned base. 


activity timelines for the two -week period of transfer operations only when the Shuttle is visiting the 
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KEY FEATURES OF INCREMENT EXECUTE PLANNING (CONTINUED) 


Logistics Operations Support: 

Integrated Flight Hardware Processing Schedules 3 Support Data 
* Flight Line " Test 3 Checkout Procedures 
Transportation System Interface Procedures 
- Integrated Logistics Systems Data including: 

Schedules , Ground operations 3 Maintenance Requirements 3 Procedures , Ground Personnel Training Plans , onboard 
Stowage Maps , ORU Configuration 3 Maintenance Histories , etc. 


III.B.2.e. Operations Execution 


Logistics Operations Support 


The Framework for real-time manned base operations 
management centers on five operations functions: 
launch site operations support (coordinated by the 
Logistics Operations Center and the Space Station 
Processing Facility); manned base systems operations 
support (coordinated by the Space Station Support 
Center), payload operations integration support 
(coordinated by the Payload Operations Integration 
Center); crew training and operations support 
(coordinated by the Space Station Support Center with 
support from the POIC); and general engineering 
support (supplied by the Engineering Support Centers). 
Together these functions (1) maintain a safe and 
consistent environment for the execution of crew 
operations (both systems and payload); and (2) 
maximize the returns from user payload operations. 
Figure HI- 12 illustrates the interrelationships among 
these functions. 


Logistics operations support functions include two 
primary types of operations activities: 1) integrated 
logistics operations performed at the launch site in a 
dedicated Program facility, and 2) prelaunch and 
postlanding processing of flight hardware performed at 
the launch site in a dedicated Program facility as well 
as at delegated remote user facilities. 


Integrated logistics operations will be managed and 
performed by the Logistics Operations Center (LOC). 
The LOC integrates Program-wide logistics support 
requirements and provides inputs to all levels of the 
planning process. This facility will procure, repair and 
provide inventory management and supply support for 
an estimated 300,000 items, including 2500 orbital 
replacement units. The LOC will be responsible for 
configuration management of these items as well as the 
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Figure III- 11 Increment And Increment Execute Planning Process Flow 
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* These operations incorporate launch site & flight crew office support as required 


Figure III- 12 Manned Base Operations Framework 
Real-Time Operations-Systems Support 


KEY FEATURES OF REAL-TIME OPERATIONS EXECUTION 

• Manned base systems support and payload operations integration activities are functionally distinct; the SSSC controls all systems 
operations and the POIC integrates the payload operations support requirements using the SSSC systems template. 

0 Off nominal (contingency) manned base systems situations are managed by the SSSC including the broad reallocation of affected 
resources. 

0 Contingency situations involving onboard payload operations are managed by the POIC without SSSC involvement if manned 
base systems or Right safety are notaffected. 

0 All remote and on-site users interface exclusively with the POIC. With the exception of EVA activities, the SSSC is generally 
transparent to the user community. 

0 Users will develop their own operations procedures within NASA standards; the POIC will review and approve user procedures 
and verify safety precautions are included as stipulated in the Increment Hazard Control Plan and other Program safety 
documentation. 

0 Logistics and processing requirements are implemented through two facilities located at the launch site. The Logistics Operations 
Center (LOO manages logistics operations functions, while the Space Station Processing Facility (SSPF) supports the prefpostRight 
space systems and user equipment processing Row. 

0 The SSSC shall assume overall responsibility for co-orbiting platform operations during maintenance and servicing missions 
conducted within the manned base 's command and control zone. 

0 The POIC shall coordinate any joint platform and manned base support by working with appropriate user representatives and the 
SSSC 
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development of flight qualification criteria for each. 
Additionally, the LOC will coordinate requirements for 
ORU in-flight maintenance with the development 
centers and provide these to the Increment 
Management Team or SSSC, as appropriate, for 
incorporation into increment execute documentation. 
The LOC will be responsible for the development, 
validation and configuration control of logistics 
standards, logistics personnel training, acquisition of 
ground support equipment, and will assist in the 
development of resupply manifests. 

The LOC will also oversee a uniform approach to the 
maintenance and upgrade of the institutional systems 
which support the Program. A key feature of the LOC 
will be extensive use of automated test equipment for 
in-house maintenance and repair. 

Prelaunch and postlanding payload processing tasks 
will be shared by users and the Space Station 
Processing Facility (SSPF). Payload integration in- 
volves up to five different steps, with users performing 
the first two: (1) the build-up of a payload at the user’s 
facility; (2) the integration of the payload into a 
payload rack or Payload Interface Adapter (PIA) 38 at 
Science and Technology Centers or regional operations 
facilities; (3) rack interface simulation and verification 
and rack-to-carrier integration performed by the SSPF; 
(4) carrier-to-launch vehicle integration performed by 
the Shuttle (or ELV) processing facilities; and (5) on- 
orbit installation and checkout by the crew and ground 
support personnel. 


Prelaunch and postlanding operations begin with the 
selection and manifesting of a user to a Station 
increment, and carry through the return of products 
and/or hardware orbit. This will require extended user 
involvement (often on a multi-year basis), with the 
user’s depth of involvement dependent on the nature of 
the user hardware and required interfaces with Station 
elements, payload carriers and the launch vehicle(s). 

Program partners will also coordinate performance of 
the first two steps of the payload integration process 
through their regional operations facilities, and deliver 
the payloads they sponsor to the SSPF for final 
interface verification. For those users who do not have 
access to a S&T Center or regional operations facility, 
the SSPF will offer the necessary integration services. 
The integrated carriers will then be delivered to the 
STS or ELV processing organization for final inte- 
gration into the launch vehicle. Provision will be made 
for late access or stowage on the pad (e.g., last minute 
delivery of biological materials) and early removal at 
landing sites of payloads from the Station logistics 
carriers. 

In addition to user payload processing, the SSPF will 
be responsible for processing Space Station systems 
hardware prior to integration into a transportation 
vehicle (the STS, or ELVs if available). 39 These activi- 
ties include the refurbishment and recertification 
(turnaround) of flight hardware (e.g., logistics carriers, 
payload racks, PIAs). The Station sustaining engineer- 
ing function will oversee the requirements for recertifi- 
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KEY FEATURES OF LOGISTICS OPERATIONS SUPPORT 

Logistics operations support activities are managed at the launch site under the auspices of a Logistics Operations Center (LOC) and a 

Space Station Processing Facility (SSPF). 

• The LOC will be responsible for the development of the manned based increment maintenance plans and assuring that the 
procedures , tools and materials to support the increment maintenance plans are available to support the increment schedules . 

• The LOC will be responsible for storage , inventory management and maintenance of all Station system parts , orbital replacement 
units (ORUs) and payload carriers. 

• Eariy/late access to the manned base logistics module will be supplied for time-critical payloads. 

e The logistics operations support framework allows for the use of a mixed fleet to provide transportation support (including 
partner-supplied vehicles). 

a Final rack-to-Station interface verification and checkout will be performed at the Space Station Processing Facility (SSPF). 
Transportation vehicle integration will be performed by the transportation system processing organizations). 

• Users wilt be able to perform payload-to-rack and PIA level integration through the establishment of Program<ertified Science 
and Technology (S&T) Centers. Users would determine S&T Center organization and structure. 

e S&T Centers may serve as representatives of discipline science and technology user groups, and may be co-located at OOCs. 
Payload-to-rack and PIA integration would be performed consistent with Station safety and interface requirements. The SSPF will 
perform experiment integration to support users who do not have access to an S&T Center. 

• The Task Force recommends a staged transition from distributed management of sustaining engineering for U.S. orbiting 
elements at the development ESCs to a centralized organization at KSC. It is assumed that this transition will occur when 
operations characteristics have stabilized sometime in the mature operations phase of the Program. 


38 A PIA is intended to support multiple external payloads , providing a single interface! attachment point to the manned base truss. 
39 Similar smaller facilities will exist at other launch sites as necessary (including partner sites). 
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cation with implementation of these requirements by 
the launch site organization (under the auspices of the 
LOC). 40 The prelaunch and postlanding processing 
flows are presented in Figures HI- 13 and El- 14. 

The framework will accommodate the development of 
partner LOC’s and SSPFs if and when foreign launch 
vehicles and launch sites are used to support the 
Station. In order to assure safety and system integrity, 
it is assumed that these facilities will have to adhere to 
the same basic standards and procedures as the KSC 
facilities, and "report” to the Program Integration level 
responsible for integrated logistics. 

• Manned Base Systems Operations Support 

During real-time operations, the SSSC (led by its 
Flight Director) is charged with maintaining manned 
base systems in working order and providing for the 
general health and welfare of the crew. SSSC responsi- 
bilities will include: space systems performance 
monitoring, resource availability assessments and 
projections, oversight of and support for increment 
changes, systems and user operations replanning, 41 


systems maintenance, housekeeping templates, crew 
safety assurance, extravehicular activity (EVA) 
scheduling and support, trajectory and altitude main- 
tenance, and command and control zone operations 
support (in conjunction with the STS Mission Control 
Center). 42 

In the interest of system safety and clear communi- 
cations paths to the Station crew, the SSSC will 
perform overall management and control of the air-to- 
ground data and voice links, and will be responsible for 
coordination of Space Station systems flight data file 
uplinks to the crew (including checklists and crew 
timelines). The POIC will be responsible for coordi- 
nating specific user operation of the data and voice 
links for payload operations, consistent with SSSC 
operations guidelines and constraints. 


The SSSC is also responsible for integration of all 
systems upgrade and sustaining engineering 
operations support provided by the various Engineer- 
ing Support Centers (both domestic and partner 
supplied — see again Figure III- 12) . The SSSC 



Figure III-13 Prelaunch Hardware Flow 
User Payloads And Station Logistics Materials 


40 Further details of the logistics support operations concept can be found in the Ground Operations Panel report . 

41 Real-time user replanning will be initiated by the IWG, and coordinated and approved by the Discipline Operations Team responsible 
for execution of that user operation and passed through the POIC to the SSSC. 

42 The manned base's command and control zone is the area within 20 nautical miles of the manned base in the fore and aft , top and 
down directions, and within five nautical miles in out-of-plane directions. Within this zone, the onboard crew maintains control authority of 
all manned spacecraft and an increased level of communication and tracking activity for STS visits. 
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Figure III- 14 Postlanding Hardware Flow 
User Payloads And Station Logistics Materials 


LAUNCH SITE PROCESSING 

The functions/responsibilities to be performed by the launch site in the implementation of prelaunch and postlanding operations 
include the following: 

0 Conduct ground operations reviews to assess / correct payload problems; 

0 Develop ground integration/test procedures from payload element inputs; 

• Perform payload physical integration/deintegration, where required; 

0 Receive payload integrated elements (racks, PIAs); 

0 Perform integrated payload mission testing on Station interface simulators for compatibility assessments and safety assurance; 

0 Perform integ ration/de integration of Space Station logistics carriers; 

0 Perform Space Station logistics carrier/payload interface testing; and 
0 Integrate and verify Space Station logistics carriers to launch vehicles 


integrates any plans for capabilities enhancements 
into the real-time operations allocations for systems 
maintenance versus user operations. 

The SSSC will provide active support to the crew for at 
least one shift per day, with a minimum level of 
support consistent with safety requirements the 
remainder of the time. Extensive use of automated 
monitoring capabilities will help to keep personnel 
requirements to a minimum. 

Other systems inputs are provided to the SSSC by the 
LOC for logistics support requirements, and by the 
Platform Support Center (PSC) for any transfer 
operations scheduling requirements for servicing of the 


Co-Orbiting Platform (COP). These inputs are 
integrated into the real time replanning effort, along 
with the user resource templates provided by the POIC 
to maximize systems performance, crew effectiveness, 
and user operations returns. 

• Payload Operations Integration Support 

The POIC (managed in real-time by the Payload 
Operations Director) will support manned base 
operations by providing the user operations 
requirements integration function for the various U.S. 
and partner-sponsored user support facilities which 
were previously described in Section I-D. (See Figure 
m 15.) This will involve the acquisition of all payload 
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SSSC RESPONSIBILITIES 

Resource Availability Assessments: The SSSC provides resource availability templates to the POIC enabling user development of 
real-time execution plans 

Resource Availability Projections: The SSSC provides resource availability projections to the Increment Management Teams (IMTs) 
working on subsequent FIPs . These projections represent the latest information available to the team since the last TOP was 
published. Projections are also made available to the Tactical Utilization and Operations Planning function for their use in 
building the TOP for the next two years of flight increments. 

Maintenance and Housekeeping Templates: The SSSC develops and maintains the standard maintenance and housekeeping 
template that reflects all routine systems operations and maintenance requirements . 

Systems Performance Monitoring and Analysis: The SSSC provides adjustments to the systems operations templates resulting 

from malfunctions or performance degradations as required by the crew and the POIC Replanning efforts in the interest of 
maintaining payload user operations are considered and implemented as possible. 

Safety: The SSSC is responsible for the safe conduct of all manned base operations, both Station systems and user systems, 
including oversight of all hazard control plans. 

Extravehicular Activity (EVA): The SSSC manages all EVA procedure development and supports EVA operations. 

Trajectory and Altitude: The SSSC monitors the orbital status of the manned base and schedules trajectory and altitude 
adjustments (coordinated with the POIC to minimize impact on user operations). 

Command and Control Zone Operations Support: The SSSC is responsible for all planning and operations for operations involving 
EVA astronauts, OMV, FTS and platforms . STS berthing operations are directed by the SSSC, and coordinated with the STS Mission 
Control Center within the Station control zone. 

Uplink and Downlink: The SSSC provides overall up/down data and voice link management and control as it affects the 
configuration of space systems and supporting ground equipment. 
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operations and servicing requirements to be performed 
onboard the manned base as well as at the launch and 
landing site. These may include operational 
requirements for transportation system interface 
(including launch environment constraints), payload 
setup or assembly, resource allocation, prelaunch/ 
postlanding/orbital servicing, transportation system/ 
manned base stowage, data collection and distribution, 
and teardown/return. The POIC will then assist users 
in the evolution of these requirements into end-to-end 
payload increment operations plans, procedures and 
schedules which are safe and which satisfy Program 
design and operations criteria. The SSSC will provide 
resource availability templates (including data 
uplink/downlink constraints) or "utilization windows” 
to the POIC to facilitate integrated user planning. The 
POIC will work with the IWG to optimally schedule 
user activities within these windows. The resultant 
plan for increment user operations will be returned to 
the SSSC for final integration with space systems, data 
systems and onboard crew activities and for 
publication of the Integrated Operations Plan for that 
increment. 

Additionally, the POIC will interface as required with 
the launch site to assist in the development and 
integration of related payload requirements into 
logistics operations support plans and prelaunch and 
postlanding processing operations plans. 

Lastly, the POIC provides real-time support to the 
accomplishment of these requirements by Program 
support and user personnel. POIC personnel will 
support the IWG and manage the daily flow of user-to- 
user and user-to-manned base interfaces. The POIC 
will arbitrate resolution of conflicts regarding 
unscheduled/rescheduled payload operations, opera- 
tions priorities, payload resource allocations, etc., and 


will represent the user to the SSSC for resource 
allocation tradeoffs between space systems and 
payloads. 

Should unforeseen schedule difficulties, resource 
constraints or technical anomalies occur in either 
payload or manned base systems operations, simul- 
taneous and complementary real-time replanning 
support will be provided to the IWG and onboard crew 
by both the SSSC and POIC in order to ensure 
minimum disruption to planned and payload 
operations activity. It is anticipated that during the 
early portion of each increment, an iterative payload 
operations replanning effort is likely to be the rule 
rather than the exception. Additionally, should 
unforeseen targets of opportunity arise for collection of 
valuable scientific data (such as the observation of a 
supernova), the POIC will coordinate IWG requests for 
special resource allocation with the SSSC to make 
these temporary allocations available (as possible) in a 
timely fashion. 43 

SSSC trajectory and altitude data, voice and command 
link allocations resource allocation updates, and 
Station crew and systems status information will be 
continuously available through the POIC as an aid to 
user replanning and operations. 

• Crew Selection and Operations 

Crew selection is integral to the entire operations 
planning and execution process. 44 The SSOTF 
recommends that the astronaut selection, assignment 
and training be coordinated by the existing Astronaut 
Office located at the Johnson Space Center. The 
Station and the STS astronaut selection and training 
programs would be distinct, based on their differing 
training requirements. (See Figure IH-16.) 45 


POIC RESPONSIBILITIES 

The Payload Operations Integration Center is a Program-supplied support service for the user community. It is the focal point of many 

of the detailed operations planning and execution activities , including: 

• Resource Allocation: The POIC supports the IWG in managing the allocation of resources to the current payload complement 
according to the rules and guidelines established in the Tactical Operations Plan and Plight Increment Plan . It supports real-time 
replanning through reallocation of resources based on space system and crew status updates provided by the SSSC 

• User Gateway to Onboard Operations: The POIC collects user requirements for voice and data link to and from the manned base. 
It then works with the SSSC to enable implementation of these requirements consistent with Program groundrules for crew 
safety , data systems utilization i, and onboard systems configuration management and control. 

e Support User Planning Activities: The POIC supports user increment execute planning and real-time replanning activities , directly 
or through their respective DOCs, ROCs e or UOFs. The POIC also serves as the users agent to the SSSC 

• Conflict Resolution: The POIC provides a dispute resolution function between users, , with final resolution authority belonging to 
the IWG consistent with safety standards monitored by the SSSC. 


43 Further details on the operations of the SSSC and POIC can be found in the Space Operations Panel report. 

“Crew training procedures are discussed in Section TV.D. 

45 Station and STS astronauts will be able to share many basic training facilities and functions, but many of the skills will differ and 
will require specialized training. For instance, Station crew will not require many of the specialized pilot skills necessary for STS 
astronauts. 
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Figure III-16 SS/STS Astronaut Organization Training Commonality 


The Task Force Framework establishes three important to recognize, however, that the extended 
astronaut classifications: Station Operator (SO), duration of flight increments implies that Payload 
Station Scientist (SS) and Payload Scientist (PS). The Scientists will have to support a variety of user 

SO and SS categories will be career astronauts, payloads in addition to the primary payload(s) which 

supplied by all the partners. Station Operators are justify their presence. 47 Hence, Payload Scientists must 

dual-function crew members whose primary emphasis be incorporated into the crew at the start of the 

is on IVA system operations, EVA, control and increment training cycle and be capable of supporting 

maintenance; secondary functions would include multiple payloads within their discipline, 

science and technology support for user payload 
operations. Station Scientists will have similar skills, 

but their focus would be reversed: the majority of their Station operations are typified by "splitting” the eight 

activity will be devoted to IVA and EVA user crew members into two four-man teams working in 

operations support. 46 Payload Scientists will be non- twelve-hour shifts (nine hours scheduled, three hours 

career crew members with skills in science, engi- on call). 48 A full crew complement would typically 

neering or technology development user disciplines. include one "special operations" team (including EVA- 

They will be flown in conjunction with unique payloads trained astronauts) and one general purpose operations 

(e.g., proprietary commercial R&D projects) which team. Special operations teams would be more heavily 

justify a non-career payload-specialized astronaut. It is "weighted" towards career astronauts, because of the 


46 EVA activities will include repair and maintenance of external components , logistics resupply , and servicing and repair of external 
payloads, the co-orbiting platform and other spacecraft. Due to the added risk and increased operational requirements in performing EVA 
(two astronauts are required for " buddy system" safety, plus one astronaut inside to provide support), EVAs wilt be minimized as much as 
possible. 

47 EVA activities will normally be performed by Station Scientists, even for user payloads. It was the judgement of the Task Force that 
the cost and complexity of training a Payload Scientist to perform EVA would rarely be warranted. 

48 Based on a 90-day stay time, each four-man team would remain on orbit for two full increments. 
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emphasis on EVA activities, while general purpose 
operations teams would offer more opportunity for non- 
career Payload Scientists. 

In addition to these "activity titles", one member of 
each shift will be designated as the Station 
Commander and will be responsible for manned base 
safety and crew coordination. Since each four-man 
team has a commander assigned during the training 
phase, one must be chosen to lead on-orbit activities for 
a specific increment. Selection will be performed by the 
Program on a case-by-case basis. A number of "rules- 
of-thumb" could be used. For example, the astronaut 
with the most manned base flight experience could be 
designated Station Commander. Alternatively, the 
Station Commander for a given flight increment could 
be the one who is completing his second increment. 
The Station Commander will be a NASA career 
astronaut with previous experience; and could be either 
a Station Operator or a Station Scientist. 

Users will have an opportunity to influence the 
selection and assignment of crews. The SSOTF 
recommends the creation of a user panel chartered by 
the Program to help define astronaut skill 
requirements for future user support and to critique 
current astronaut performance of user operations 
support activities. This panel will recommend 
scientists, engineers and technologists for selection as 
Station Scientists and Payload Scientists, and will 
periodically review the Program's flight crew policies 
and practices as they affect the quality of payload 
operations. 

Crews will be assigned, trained and flown as unified 
teams to enhance safety and promote efficient 
operations onboard the manned base. Career astronaut 
candidates will be selected by the astronaut 
organization, with suggestions from Station- chartered 
user panels. The JSC Astronaut Office will make the 
final astronaut selection recommendations and forward 
them to the head of the utilization and operations 
organization. Increment assignments will be made by 
the JSC Astronaut Office. Payload Scientists will be 
nominated by the user community. Their nomination 
procedures shall be user-defined, but must conform 
with minimum Program astronaut qualification 
standards. Final approval of PS candidates will be 
made by the head of the utilization and operations 
organization, based on the recommendation of the JSC 
Astronaut Office. International participation in this 
process is expected, and will be specified by MOUs. 

The JSC astronaut organization will define the skill 
requirements (e.g., minimum levels of training, 
physical condition, etc.) needed by all career Station 
astronauts. It is assumed that "basic training" for all 
new astronauts will take approximately 30-36 months, 
equivalent to the current profile for STS astronaut 
training. Assigned crews will train as a team for 
approximately eighteen months prior to launch for 
specific payload and systems tasks assigned to their 
flight increments. Between missions, it is assumed 
that Station scientists will work closely with the users 
in payload and experiment definition and procedures, 
while Station operators will spend a significant 
amount of their time assisting with the Station's 
sustaining engineering and operations functions. 


• Engineering Support Operations 

NASA and its partners must provide an ongoing 
engineering support capability to the Program for 
sustaining the performance of baselined space systems. 
This support will be provided through distributed 
Engineering Support Centers (ESCs) located at each 
NASA and partner element development and launch 
center. ESCs will provide personnel and technical 
analysis capabilities to support routine space systems 
sustaining engineering activities as well as "on call” 
support to the Station execute teams for analysis of 
unanticipated situations onboard Station elements. 

Space Systems sustaining engineering can be divided 
into three major categories: systems maintenance 
engineering (engineering required to keep baselined 
space systems operating at peak performance); systems 
design engineering (engineering analyses performed in 
support of design modifications); and payload inte- 
gration engineering (engineering in support of user 
payload operations and integration). 

- Space Systems Maintenance Engineering: This 

category includes the engineering support 
required to keep space systems operational. This 
consists of planning and execution support 
provided by the launch site and development 
center ESCs on space systems OKU hardware, 
and ESC analyses of assigned flight hardware, 
including: engineering analyses, safety 

analyses, anomaly tracking and disposition, 
maintenance procedures development and 
verification, modification, repair, installation, 
testing and flight certification. It also includes 
the management, control, ground personnel 
training and scheduling required to perform 
these activities, as well as technical coordination 
with contractors and Program interfaces (e.g., 
development activities). 

- Space Systems Design Modifications Engineer- 
ing: This activity will be performed by the 
development center ESCs (routinely or upon 
request) on their assigned space systems 
hardware and software, including: performance 
and trends analyses, safety analyses, anomaly 
tracking and flight hardware systems disposi- 
tion, design engineering, procedures develop- 
ment and verification, modification, repair, 
installation, testing and flight certification. 
This also includes the management, control, 
ground personnel training and scheduling 
required to perform these activities, as well as 
technical coordination with other ESCs, 
contractors, and Program interfaces. 

- Payload Integration Engineering: This category 
supports user payload operations and 
integration at the launch site or development 
center ESCs (routinely or upon request) on 
Program-approved payloads, including: space 
systems compatibility analyses, safety analyses, 
payload-to-element integration, payload-to- 
Station integration, and development of test and 
checkout procedures. It also includes launch site 
installation, testing and flight certification. 
Additionally, it includes the management, 
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control, ground personnel training and 
scheduling required to perform these activities, 
as well as technical coordination with users, 
other ESCs, contractors, and Program inter- 
faces. 

As the operations of the various space and ground 
support systems becomes routine and their operating 
characteristics become more predictable and stable, the 
SSOTF suggested centralizing the sustaining 
engineering function for space systems at the launch 
site(s). 49 This entails transitioning the sustaining 
engineering expertise in a gradual manner from the 
distributed development centers and their geograph- 
ically dispersed contractors to a corresponding set of 
expertise at the launch site(s). 

Focusing space systems sustaining engineering at the 
launch site(s) takes advantage of the "hands-on” 
hardware engineering expertise developed by the 
launch processing teams; provides central locations for 
integration, test, and verification of system and 
payload interfaces; and centralizes and simplifies the 
development of on-orbit maintenance procedures. The 
transition will also gradually relieve the development 
centers of their responsibility for the more routine 
aspects of Program operations and permit them to 
transition engineering skills back into design and 
development activities. 

Many of the facilities necessary to support this 
suggestion will be in place at the launch sites (e.g., test 
and integration facilities and logistics operations 
facilities). However, there will be some additional 
costs involved in relocating specific system and 
subsystem testbeds and prototypes from the 
development centers to the launch site(s). There may 


also be requirements to develop training capabilities 
and facilities at the launch site(s) to train crews for on- 
orbit sustaining engineering or repair tasks. 

The suggestion must also take into consideration the 
fact that the development centers (both NASA’s and its 
Partners’) will have built up approximately ten years 
of "organizational inertia” during the development, 
assembly, and early operations phases of the Program. 
This will lead to some risk not only in transitioning 
responsibility away from the development centers, but 
also in acquiring and retaining the correct engineering 
skill mix at the launch site(s). While the idea of 
eventually centralizing the responsibility for space 
systems sustaining engineering at the launch sites 
appears to have merit, the SSOTF encourages more 
detailed studies to determine the feasibility, benefits 
and costs associated with this suggestion. 

Summary 

Figure III-17 summarizes the explanation of the 
manned base Recommended Framework and indicates 
a number of key features. Strategic utilization 
planning is performed at the national level, with user 
resources allocated to the partners via MOU 
provisions. Users will steer the utilization planning at 
this level for the U.S. via their inputs from the SSUB. 
The Station operations organization will integrate the 
national utilization plans with Station systems 
maintenance requirements to form the five-year CUP, 
two-year TOP and various FIPs. Users will participate 
at all management levels of the Program. However, 
the Station Program will retain control over and 
perform the functions associated with overall manned 
base space operations. The international partners will 
be integrated at all management levels of the Program. 


49 Responsibility for sustaining engineering of the ground support systems would remain distributed to respective NASA and Partner 
operations centers. 
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Figure III-17 Summary: Manned Base Operations Framework 




















III.B.3. Platform Operations Framework 

The Platform Operations Framework addresses the 
U.S. co-orbiting and polar platforms (COP and POP 
respectively). The European Space Agency (ESA) is 
also providing a polar orbiting platform. Although 
ESA platform requirements will be included in overall 
program planning, it will operate independently of the 
U.S. platforms. Hence, operation of the ESA platforms 
is not addressed by this Framework. 

The Task Force developed a separate Framework for 
platform operations. The primary reason for doing so is 
that except for servicing of the co-orbiting platform at 
the manned base, the COP and POP have considerably 
different operational characteristics and functional 
requirements. Platform systems operations are 
controlled exclusively from the ground whereas the 
manned base will be controlled by the ground and by 
the onboard crew. The unmanned platforms will carry 
a smaller complement of payloads than the manned 
base (perhaps only one "facility class" instrument). 
They will also operate for several months or even years 
without requiring servicing, payload changeout, or 
manned interaction. With the exception of enhanced 
opportunities for servicing of the co-orbiting platform, 
planning and conducting platform operations in the 
Space Station era will not be significantly different 
from present-day unmanned satellite operations. 

Although largely independent from manned base 
operations, the platforms will share common support 
services such as engineering support, transportation 
and logistics services, and tracking and data relay 
services. Commonality will also be provided at the 
systems/O RU-level for the spacecraft (e.g., basic power 
systems, communications and tracking, user 
interfaces, and the basic data management system). 

The recommended Platform Operations Framework 
reflects the unique operational requirements of these 
unmanned spacecraft. Figure III- 18 illustrates the 
most likely early utilization of the platforms: an earth 
observing mission for the POP and an astrophysics 
mission for the COP. These representative configura- 
tions reflect a significant difference between the 
platforms and the manned base; each platform will 
essentially be a unique spacecraft reflecting the 
Mission Sponsor's payload requirements. (I.e., most 
platforms are likely to be "mission-unique," although 
there are provisions for "multi-mission” platforms 
supporting different science disciplines). 

The Space Station Program's unmanned platforms will 
support a variety of science and technology users. They 
may also support operational missions such as weather 
observation and land and ocean resources mapping. 
The co-orbiting platforms may also be used to support 
commercial space research or commercial processing 
and manufacturing. Figure III- 19 illustrates the 
Platform Operations Infrastructure supporting not 
only the on-orbit phases, but the planning, scheduling, 
prelaunch, and ground support activities necessary to 
conduct the mission of the platform and its payloads. 

The SSOTF investigated a number of alternatives for 
Platform Mission Management. These alternatives 
divide the overall functional responsibilities for 
managing a particular platform mission between the 
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Space Station Program and the user. Functional 
responsibilities for mission management support fall 
into four categories; (1) Platform Supplier; (2) 
Platform operator; (3) Payload operator; and (4) other 
Mission Support (i.e. launch support, institutional 
support, payload development, and payload integration 
with the platform). 

The Platform Mission Manager is responsible for 
coordinating and managing each of these functional 
areas to provide the services and capabilities necessary 
to achieve the mission success criteria. Table IH-7 
provides a summary of the various mission 
alternatives developed by the SSOTF to characterize 
platform operations. 

The SSOTF observed that short term missions appear 
to be more applicable to Alternatives 1 and 2; long term 
missions appear to be more applicable to Alternatives 4 
and 5. "Quick is Beautiful" user missions for platforms 
appear to be more applicable to COP missions managed 
under Alternative 1. 

For short term missions it is desirable to leave 
sustaining engineering responsibilities with the 
Platform operator. For longer term missions, 
sustaining engineering responsibilities could be 
transferred to the user but maintenance of this 
capability will be difficult. 

The SSOTF concluded that: (1) the program should not 
preclude the selection of any alternative; (2) the 
selection of the Mission Management alternative 
should be made on a mission-by-mission basis; and (3) 
the first COP and POP platform mission should 
initially be managed under Alternative 1 to ensure 
accomplishment of Program engineering, utilization 
and operations objectives. After successfully 
demonstrating the platforms' capabilities, alternatives 
4 and 5 may be implemented on future platforms. The 
Station Program should also retain responsibility for 
planning and conducting any Transfer operations for 
early platforms and payloads. 


III.B.3.a. Strategic Utilization and Operations 
Planning 

Figures III-20 and 21 summarize the end-to-end 
planning process for the U.S. polar and co-orbiting 
platforms. The major difference between the POP and 
COP processes is that the COP transfer (servicing) 
operations planning is fully integrated into the 
manned base planning flow. Similar to the manned 
base, these two planning processes serve as the focal 
point for describing the Platform Operations 
Framework. 

Program Policy level planning is common with manned 
base strategic planning in order to provide overall 
Program planning coordination (provided through the 
CUP). Platforms will be managed by the contributing 
partner at the Program Integration and Program 
Execution levels. (The U.S. and ESA platforms will be 
managed independently.) Platform tactical planning 
and operations execution are also independent of the 
manned base except for COP transfer operations 
requiring manned base servicing activity. 
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Table III-7 Platform Mission Management Alternatives 



• ASTROPHYSICS TELESCOPE CONFIGURATION 

• ORBIT ALTITUDE: 463 TO 1000 Km; INCLINATION 28.5° 

• LAUNCH SEQUENCE: AUGUST, 1996 

• SERVICING AT SHORTER THAN 2 YEAR INTERVALS FOR 
CRYOGEN REPLENISHMENT 

• LONG MISSION LIFE:10 TO 15 YEARS 

• LAUNCH VEHICLE: STS AND OMV 

• USER REQUIREMENTS: SIRTF AND AXAF 

• PEAK DATA RATE: <6 Mbps 



• EARTH OBSERVING MISSION DRIVEN 

• ORBIT ALTITUDE: 500 TO 900 Km (OPERATIONAL) 

- INCLINATION 98° (APPROXIMATELY) 

-SUN SYNCHRONOUS 

• DEPLOYMENT ALTITUDE: 240 KM 

• SERVICING ALTITUDE: HIGHER THAN 240 KM 

• LAUNCH SEQUENCE: NOVEMBER 1993 

• LAUNCH VEHICLE: STS AND PLATFORM PROPULSION 

OPTION: ELV AND PLATFORM PROPULSION (INITIAL DEPLOYMENT) 

• PEAK DATA RATE: 300 Mbps 

• SERVICING: AFTER 1-2 YEARS TO ADD PAYLOAD AND EXCHANGE 

PROPULSION MODULE IF STS LAUNCHED 

• LONG MISSION LIFE: UP TO 30 YEARS WITH SERVICING 

• USER REQUIREMENTS: MISSION REQUIREMENTS DATA BASE 


CO-ORBITING PLATFORM (COP) 


POLAR ORBITING PLATFORM (POP) 


Figure III- 18 Orbiting Platforms 
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Figure III-19 Platform Operations Infrastructure 
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Figure III-20 Platform Operations Framework - Polar Orbiting Platform 
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Figure III-21 Platform Operations Framework - Co-Orbiting Platform 


One of the major strategic decisions made by the Space 
Station Program's Mission Manager and the user's 
Mission Sponsor is a definition of the combined 
platform and payload configuration. As with manned 
base payloads, the Space Station Program does not 
define or select the payloads; that is the responsibility 
of the Mission Sponsor. The Mission Sponsor, with 
active support from individual users, selects payloads, 
establishes priorities, and develops requirements for 


system enhancements of new platforms. The Program 
reviews proposed mission objectives, approves the use 
of Program resources, and commits the Program to 
support. 50 

Key functions performed at the Program Policy level 
parallel those performed for the manned base and 
include: (1) mission analyses for the platform, 

payloads, and required systems support, as well as 


i 


PLATFORM OPERATIONS 

On-orbit platform operations are characterized by two distinct phases during which the platform will be operated to perform either a 
series of "missions, 9 or a single mission for the life of the platform and its payload. These phases are Platform Payload operations and 
Platform Transfer operations. 

Platform Payload operations: These are the activities performed to meet mission objectives and success criteria . They are comprised of 
the platform flight and ground systems ; the platform ’s integrated payloadfs) flight and ground systems, and supporting systems (e.g. f 
information systems). These day-to-day payload operations focus on providing required support services to onboard payload users. 

Platform Transfer operations: These activities include: ( 1) initial launch operations, transfer to operational orbit, and spacecraft test 
and checkout; (2) on-orbit servicing and maintenance operations for both the platform and its payloads ; and (3) recovery or re-entry 
operations to remove a platform and its payfoadfs) from orbit. 

The Platform Support Center (PSC) at the Goddard Space flight Center is responsible for planning and controlling each of these two 
phases Other capabilities are provided by the Space Station Program , space transportation systems , and the platform users The 
Space Station Information System (SSIS) provides both operational and administrative communications services among all ground 
locations as well as the space- to- ground services linking the PSC and the users to the platform and its payloads 


S0 While there are a number of alternatives for platform Mission Management, for simplicity in illustrating the Platform Operations 
Framework, Alternative 1 from Table III-7 is assumed. Hence, the Platform Supplier, Mission Manager, and Platform Operator are 
assumed to be provided by the Space Station Program. The Mission Sponsor and Payload Operator are provided by the user community. 
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definition of support requirements for transportation, 
logistics, and tracking and data relay systems; (2) 
platform, payload, and transportation system 
compatibility assessments; (3) definition of platform 
systems resource requirements; (4) definition of the 
final platform configuration; (5) preparation of 
preliminary implementation and operations plans; and 
(6) the preparation of preliminary transfer operations 
plans. The results of these activities serve as inputs to 
the Consolidated Utilization Plan (CUP). 

III.B.3.b. Tactical Utilization and Operations 
Planning 

It is anticipated that platform increments (time 
between STS or manned base maintenance and 
servicing activity) will vary greatly in duration, 
depending on platform mission objectives and planned 
orbital lifetime. This results in the need to maintain a 
flexible approach to the flow of utilization and 
operations planning documentation at all management 
levels. Given the temporal scope of the CUP (5 years) 
and the TOP (2 years) and the fact that platform 
increments are, in any case, much longer than their 
manned base counterparts, a platform’s planning 
documentation complement will either consist of a 
CUP, a TOP, and the various execute plans and data, 
or simply of a CUP and the supporting execute plans 
and data. A manned base-type FIP will not be 
required. 51 

Platform planning activity largely focuses on pre- 
launch activities. Once on orbit. Program Integration 
level planning is conducted periodically to update the 
initial plan. However, these updates are not on a fixed 
cycle or keyed to a "flight increment" as with manned 
base operations. Instead, they are highly dependent 
upon the specific instruments or payloads for which a 
given platform mission has been defined. 52 In many 
cases the replanning cycles will be influenced by 
mission drivers such as seasonal earth observing 
cycles. 

The Mission Management organization serves in the 
same functional capacity for a single platform as the 
POCB does for the manned base. The Mission Manager 
will be supported by an Investigators Working Group 
(IWG), consisting of representatives from the users and 
the platform instrument(s) development team. The 
IWG will formulate recommendations regarding 
science planning and implementation, and conflict 
resolution support for user-related planning and 
operations issues. 

The Platform Mission Manager leads the Program 
Integration level planning process (similar in many 
ways to the Increment Change Manager's role in 


supporting the tactical and increment planning 
processes for the manned base). This process includes 
developing integrated platform and payload develop- 
ment schedules; scheduling and acquiring re-quired 
transportation and support services; developing and 
conducting integrated tests; coordinating payload 
requirements with the Mission Sponsor and individual 
investigators; coordinating the formation of an 
Investigators Working Group (IWG) with the Mission 
Sponsor and user community; defining data types, 
flows, processing, and display requirements; establish- 
ing and administering Program schedules and budgets; 
and integrating user and platform system plans and 
procedures into an Increment Operations Plan (IOP). 
As in the manned base Framework, the Program will 
assign a Payload Accommodation Manager (PAM) to 
assist users through the planning process, as well as 
the integration, testing and verification of the user's 
payload. 

Once on orbit, platform operations are not subject to 
frequent changes in configuration and do not have 
frequent/ routine visits by the STS or servicing from 
the manned base and their crews. When these changes 
do occur, they are reflected in a separate Platform 
Transfer Operations Plan (PTOP). For COP servicing, 
the Platform Transfer Operations Plans are fully 
integrated into the manned base planning flow. 53 


III.B.3.C. Operations Execution 

Platform Operations Execution is functionally divided 
between platform systems support and user operations 
support. The Program Execution level plans identify 
the sequence of activities, resource requirements, and 
timelines required to be executed by both ground and 
flight systems. User requirements are reflected in 
three areas: (1) payload scheduling; (2) real-time 
payload support and instrument operations; and (3) 
engineering and payload data capture. 

Payload scheduling covers the development of specific 
requirements for instrument operations and payload 
data collection. Execution plans are generated as 
required on an orbital, daily, or weekly basis. These 
plans are then translated into command files which are 
uplinked to the platform to control and manage the 
platform and payload configuration. 

Real-time payload support and instrument operations 
include monitoring and coordinating users and 
platform systems operations (conducted by the PSC). 
Users operating in telescience mode may command an 
instrument in real-time in response to observed data. 
Other real-time (or near real-time) activities could 


51 In the case where a platform is to be maintained and serviced by the STS or manned base at intervals greater than two years ( i.e ., an 
increment duration beyond the scope of the TOP), the CUP data is used directly to generate execute plans and data; in the event the servicing 
interval is less than two years, a TOP will be required as an interim step to define multi -increment servicing and maintenance requirements. 

52 The difference in operations of a POP accommodating earth observation missions, and the operation of a COP accommodating an 
astrophysics mission (such as a large telescope) precludes a generic definition of Program Integration or Program Execution level planning 
"increments. " 

S3 The SSOTF concluded that the feasibility of POP servicing requires more study due to concerns over transportation availability , EVA 
risk, platform complexity and cost to execute the de-orbit and return to operational orbit transfer maneuvers required by STS servicing . If 
deemed feasible, POP Transfer Operations Plans would be coordinated and developed with the STS Program. 
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include: fault isolation and restoration and replanning 
to respond to system/payload anomalies; or imple- 
menting a change in instrument operations generated 
by the user in response to "quick-look” data analysis. 

U.S. platform payload and platform transfer operations 
will be managed and controlled by a Platform Support 
Center (PSC). 54 The PSC functions for platform 
systems control and user support are analogous to the 
SSSC and POIC functions in the manned base. Support 
to users for payload operations will be coordinated in 
the PSC by the Platform Payload Operations Center 
(PPOC). Actual payload operations will be performed 
by individual users in user facilities. Platform transfer 
operations will be planned and conducted in the PSC by 
the Platform Transfer Operations Center (PTOC). The 
PTOC will support specialized servicing planning 
requirements and interface with the manned base and 
STS increment planning activity. Transfer operations 
will be managed by the STS operations organization 
when the STS or STS-based OMV is the servicing 
vehicle, and by the SSSC when these operations are 
performed by the Station-based OMV, or when the COP 
is brought within the 20 nm command and control zone 
for servicing at the manned base. 55 

The final products of user execution operations are the 
reports and analyses resulting from the capture and 
processing of the downlinked instrument data. 
Platform systems data are also downlinked, captured, 


and processed by the PSC to provide systems trend 
analyses, support anomaly investigations, and support 
the development of maintenance procedures. Systems 
data may also be required by the users to support their 
analysis of instrument data. A detailed planning flow 
reflecting these activities for Platform Operations 
Execution is illustrated in Figure lH-22. 56 


As with the manned base, platform operations will be 
supported by the Program's Engineering Support 
Centers (ESC), Logistics Operations Center, Space 
Station Processing Facility, and the space transpor- 
tation systems. The Space Station Information System 
supports user telescience requirements by providing 
direct access to platform payloads. The SSIS also 
provides the required communications connectivity 
among all of the other locations illustrated in Figure 
m-19. 

Figure IQ-23 provides a summary flow of the platform 
operations framework from strategic planning through 
operations execution for normal platform payload 
operations. Figure IQ-24 augments this overview by 
adding the activities required to conduct transfer 
operations as well as indicating the requisite interfaces 
with the manned base operations structure. These 
figures summarize the explanation of the platform 
operations framework developed by the SSOTF, and 
indicate a number of key features. 



Figure III-22 Platform Operations Execution - Functional Flow 


54 The ESA platform(s) will be controlled by a separate ESA control center. 

56 The COP will normally be maneuvered into the same orbital inclination as the manned base, permitting servicing by any of these 
methods. The POP will only be serviced by the STS , possibly in conjunction with an OMV, at the operational altitude of the Shuttle in polar 
orbit. The Program baseline assumes STS launch and use of STS or manned base with OMV for servicing. 

56 A parallel discussion and illustration for Transfer Operations is contained in the Space Operations Panel report. 
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Figure III-23 Co-Orbiting And Polar Platforms 
Payload Operations Framework Overview 
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SUMMARY FEATURES: PLATFORM OPERATIONS FRAMEWORK 

• Platform Program Policy level planning is common with manned base strategic planning to provide overall Program planning 
continuity . Program Integration level planning varies in scope according to platform increment duration . Program Execution 
level planning and mission execution coordination is performed by the PSC. 

• Each platform is separately managed by the Program contributor at the Program Execution level; the U.S. manages its COP and 
POP, ESA manages the ESA polar platform. 

• Program Integration and Program Execution level operations are independent of manned base operations except for COP 
Transfer operations (manned base servicing of the Co-orbital Platform). 

• The Framework assumes commonality in systems hardware down to the ORU-level to support cost savings in design , development 
and operations. 

• U.S. platform operations are managed at a centralized Platform Support Center located at GSFC with the following features: (1) 
operations are modeled after past platform experience ; (2) remote user operations (telescience) will be a standard mode of 
operation; and (3) sustaining engineering support is shared with the manned base for common systems. 


III.C. ORGANIZING FOR OPERATIONS 

III.C.l. Organizational Philosophy 

As specified in its charter, the SSOTF analyzed 
alternative Space Station operations organizations to 
implement the Recommended Framework for the 
Mature Operations Phase of the Program. These 
alternatives were then examined for their applicability 
to both the Development and Evolutionary Phases of 
the Program. 

Based on this analysis, the Task Force recommended 
that the Program should create immediately a Space 
Station Operations Organization separate from the 
Space Station Development Organization. This 
separation should continue throughout the assembly, 
verification, mature operations and evolutionary 
Program phases. The Task Force based this recommen- 
dation on the following principal characteristics of the 
Station operations environment: 

(1) The NASA administrator has recently directed 
key Agency personnel and several study groups to 
analyze and make specific recommendations to 
better focus multi-program spaceflight operations 
across the Agency from an organizational 
perspective. The above SSOTF recommendation is 
consistent with this effort. 

(2) The Space Station operational "system” will be 
quite large, encompassing multiple NASA centers, 
several international partners, and numerous 
technically and functionally complex disciplines. 
Many of these groups have not been integrally 
involved in the "operations" aspects of previous 
manned space programs (e.g.. Program marketing 
and logistics support). The situation will be further 
complicated as the Mature Operations Organization 
takes on user integration and sustaining engineer- 
ing responsibilities, while the Development Organ- 
ization moves on to develop Station evolutionary 
systems and support other NASA initiatives. 

Thus, the management effort required to develop 
and implement an initial operations capability for 
this system will be as great as that required to 
develop and verify the spacecraft systems. The 
establishment of a separate Operations Organi- 
zation in the near term will allow both the 
Development and Operations Organizations to 


develop the necessary systems, procedures and 
expertise by the time of initial element launch, and 
will allow the Operations Organization to mature 
along with the technical capabilities of the 
Program. 

(3) The SSOTF anticipated that the U.S. Executive 
and Legislative Branches would continue to be 
concerned with the prediction, management and 
control of annual Space Station operations costs 
throughout the life of the Program. An organiza- 
tional structure which clearly differentiates 
operations support functions from those associated 
with systems development would facilitate 
operations cost management and control. It would 
support the projection of ongoing operations perfor- 
mance and costs by primary function, measurement 
of operational resources expended over each opera- 
tions increment, and collection of overall operations 
resource utilization data. This approach would also 
minimize any budgetary conflict of interest between 
the development of flight systems hardware and 
software and the development of ground-based 
operations support systems. 

Additionally, the Office of Space Station should begin 
immediately to establish Program interface agree- 
ments with each NASA institution which will support 
Station operations. This includes interfaces between 
the Station Program and each affected Associate 
Administrator and Center Director. These agreements 
will serve to broadly define the various Center 
commitments which will subsequently become a part of 
their Program Operating Plan submittals during the 
Development and subsequent Mature Operations 
Phases of the Program. Typically, these agreements 
should cover the significant institutional manpower 
requirements and requirements for development or 
enhancement of critical support centers, facilities, and 
systems. They must also cover the major commitments 
by the NASA transportation systems providers as well 
as the providers of communication and data systems 
services. 

Evaluation Criteria 

The SSOTF recognized that any operational organiza- 
tion which it recommends must conform to NASA 
policy concerning Headquarters-centralized manage- 
ment control as well as with overall Program goals. 
Specifically, these criteria included: 
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(1) The organization must be hierarchically and 
functionally structured to centralize Program man- 
agement and control at NASA Headquarters, with 
Program implementation support distributed as 
appropriate to participating NASA centers. 

(2) The organization must provide clearly defined 
user interfaces to the Program at each hierarchical 
level, and must integrate user requirements so as to 
minimize the number of these interfaces. 

(3) The organization must provide for effective and 
politically acceptable international participation at 
each hierarchical level and within each level's 
organizational elements, while preserving NASA's 
role as overall Program leader. 

(4) The organization must clearly define the 
Program support functions assigned to each 
participating NASA center while leaving each 
center flexibility regarding specific implementation 
approaches (e.g., project vs. matrix organization). 


(5) The organization must be able to adapt to 
accommodate the varying requirements of the 
Program’s phases. 

After considering these criteria and other anticipated 
characteristics of the Program operations environ- 
ment, the SSOTF recommended a Mature Operations 
Phase organizational structure as illustrated by Figure 
m-25. It should be noted that although the SSOTF 
assumed that this organization would be directed by an 
Associate Administrator (AA) for Space Station 
Operations, the hierarchical distribution of functions 
would remain generally valid if incorporated into an 
agency-wide Office of Space Operations (i.e., an organi- 
zation including Space Station, space transportation, 
and tracking and data systems operations). Specific 
modifications, however, would require further 
analysis. 

It was determined that although this recommended 
Mature Operations Organization was readily adapt- 
able to the requirements of all Program phases, some 
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modifications will be required during the Development 
Phase to better focus on operational capability 
development and to support assembly operations 
planning and execution. These modifications will be 
described in a subsequent section in terms of specific 
changes to the Mature Operations Organization. The 
modified Transition Operations Organization structure 
is illustrated by Figure IEE-26. 

Finally, the Task Force did not identify specific 
changes to the Mature Operations Organization 
required to support Space Station evolution, since this 
phase involves gradual development of technical 
operations capabilities rather than a discernable 
Program phase. Since evolutionary changes must be 
supported throughout the operational lifetime of the 
Space Station, the basic evolutionary operations 
planning and support capability must be embedded 
within the Mature Operations Organization infrastruc- 
ture. 

III.C.2. Proposed Structure 

IILC.2.a. Mature Operations Phase Organization 

This section describes the operations functions 
performed by each organizational element in Figure 
EH-25. Specific recommendations regarding NASA 


field center operations roles are identified for each 
element, as are key products and interorganizational 
relationships. Routine organizational element func- 
tions that may be generically labeled administrative 
overhead 57 are not listed for each element. 
Organizations that are external to the Space Station 
Program but which provide significant support to the 
Space Station Operations Organization are indicated 
on the referenced figures; however, their specific 
organizational structure and functions are not 
described. 

(1) Program Policy Functions (NASA 
Headquarters): 

Office of Space Station Operations: This office 
supports the NASA Administrator in all matters 
pertaining to Space Station Operations. The Associate 
Administrator (AA) for Space Station Operations 
exercises overall Program management and control, 
and serves as principal liaison between the NASA 
Administrator and organizational elements of the 
Space Station Program. As such, the AA authorizes 
and controls all operations functions, products and 
services performed by each hierarchical element within 
the Program structure. As chairperson of the 
international Multilateral Control Board, the AA 
exercises Program leadership across the international 
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^Includes organizational element resource management, product schedule development , personnel management , support contractor 
technical oversight and performance reporting. 
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partnership and is responsible for all decisions 
affecting Program direction, scope, content and safety. 
As a member of the Space Station Users Board, the AA 
represents those categories of users sponsored by the 
Space Station Operations Program in matters regard- 
ing specific user selection and resource allocation 
(mainly commercial reimbursable users). The 
Operations AA is the primary focal point for interface 
with other NASA AAs as regards their support to or 
interaction with the Space Station Operations 
Program, 

Program Scientist: The Program Scientist at the 
Program Policy level serves as a consultant to the AA 
on matters pertaining to: 

• Domestic and international science, technology 
development, and commercial Space Station 
Program utilization opportunities; 

• Liaison to various user advocacy groups; 

• Support to prospective and selected users relative to 
their development of payload operations require- 
ments and objectives; 

• Support to evolutionary planning; and 

• Serves as chairman of the Utilization Operations 
Panel (UOP). 


Utilization and Operations Development Division: 

This office supports the AA as the SSP advocate to the 

user community at large. As such, the office: 

• Develops and implements user outreach (market- 
ing) strategy; 

• Responds directly to user inquiries; 

• Coordinates negotiation of "best efforts contracts" 
with prospective users or their sponsors to fly their 
payloads; 

• Coordinates implementation of partner account- 
abilities and responsibilities per MOU agreements; 

• Maintains a strategic operations planning "systems 
and services" data base containing current and 
projected resource availability information on 
transportation vehicles, the manned base, U.S. and 
partner platforms, OMV/FTS, and ground support 
facilities; 

• Provides chairpersons as required to support the 
international Systems Operations Panel (SOP); 

• Integrates and publishes the international Consoli- 
dated Utilization Plan in response to SOP and UOP 
requirements; 

• Maintains functional descriptions of selected 
payloads and their operational objectives; 

• Supports evolutionary planning with respect to 
future user requirements; and 


• Leads in user selection and resource allocation for 
commercial reimbursable and commercial develop- 
ment users, and provides marketing support to 
other U.S. users. 

Strategic Policy Division: This office supports the 
AA in the development and implementation of Space 
Station Program policy relative to international, 
domestic non-NASA and internal NASA Space Station 
Program operations, including: 

• International partner or user Memoranda of Under- 
standing (MOU) negotiations; 

• Staffing coordination of NASA/partner internation- 
al liaison offices; 

• Interaction with Executive and Legislative Branch 
staff offices and committees; 

• Interaction with non-NASA government organi- 
zations including the Department of Defense; and 

• Definition of Space Station Program goals, 
objectives and strategic-level operational require- 
ments. 

Program Management Division: This office 

provides support to the AA in matters regarding: 

• Multilateral Control Board logistics; 

• Strategic operations policy analysis; 

• Strategic requirements and plans control; 

• Program risk assessments; 

• Determination of Program operations costs; 

• Development of organizational performance and 
cost measurement criteria and approval of 
techniques for assessments of overall organizational 
effectiveness, supportability and guidance in 
defining long-term Program improvements. 

The office is also responsible for operations budget 
planning and control including. 

• Coordination and support to Program Operations 
Plan (POP) development, defense and representa- 
tion of requirements to other organizations and 
agencies, and oversight of program resources 
acquisition; 

• Primary support to pricing and cost sharing policy 
development; and 

• Program milestones development and statusing. 

Evolutionary Planning Division: This office 

supports the AA in planning for Program evolution 
operations including: 

• Definition of Program evolution goals; 

• Ongoing interaction with the Program Integration 
and Execution levels of the organization to obtain 
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feedback regarding overall operations effectiveness 
and growth potential/needs; 

• Development of evolutionary operations require- 
ments; 

• Conduct of Program Policy level planning for 
enhancement of ground and onboard resources; 

• Management of contractor and field center studies 
in evolutionary operations; 

• Leads in planning and control of evolutionary 
advanced development requirements for Space 
Station technology; and 

• Interaction at the Program Policy level with the 
Evolutionary Systems Development Organization 
regarding implementation of evolutionary opera- 
tions requirements. 

(2) Program Integration Functions (NASA 
Headquarters): 

Office of the Director, Utilization and Operations: 
The NASA Director, Utilization and Operations, 
supports the Associate Administrator and has dele- 
gated responsibility and authority to administer and 
control the overall Program Integration and Execute 
Level operations functions within the SSP. This 
includes: 

• Control of baseline SSP orbiting and ground support 
elements configuration; 

• Control of Program Integration Level operations 
requirements and plans; 

• Chairing the Program Operations Control Board; 

• Ensuring effective accommodation of user require- 
ments for Program integration including Program 
Integration and Execution level operations plan- 
ning and implementation; and 

• Approval of astronauts qualified to fly on the Space 
Station. 


Program Scientist: The Program Scientist at the 

Program Integration level serves as a consultant to the 

Director, Utilization and Operations on matters 

pertaining to: 

• Domestic and international science, technology 
development, and commercial Space Station 
Program utilization opportunities; 

• Liaison to various user advocacy groups; 

• Support to prospective and selected users relative to 
their development of payload operations require- 
ments and objectives; 

• Support to evolutionary planning; and 

• Review and assessment of current SSP laboratory 
procedures and practice. 


Program Analysis and Support Office: This office 
provides support to the Director, Utilization and 
Operations in matters regarding budget administra- 
tion and cost control including: 

• POP construction and defense; 

• Program resource management; 

• Support to pricing and cost-sharing policy develop- 
ment; 

• Operations cost model development and analysis; 
and 

• Analysis of life cycle cost trades. 

The office also provides administrative support in 
areas of: 

• Program schedules development and analysis; 

• Program Support Contract management, perfor- 
mance measurement and award fee assessment; 

• Support to Program Operation Control Board 
logistics; 

• Configuration control of Program documentation; 
and 

• Maintenance of a Program Documentation Library. 

Increment Change Management Office: This office 
provides support to the Director, Utilization and 
Operations, and has the delegated responsibility and 
authority to manage manned base/platform Program 
Integration level preflight operations planning 
functions at the Increment Planning level. This office 
provides a cadre of Increment Managers to direct the 
unique operations planning aspects (systems mainte- 
nance, new payloads, servicing requirements, trans- 
portation systems interface including ELV visits, etc.) 
associated with each flight increment. Increment 
Managers steer utilization of manpower and funding 
resources available for their increment, and provide 
feedback to institutional support organizations relative 
to the performance of planning support personnel and 
operations support systems. This office will be staffed 
by senior operations personnel and may have 
international partner representatives in Increment 
Manager positions. 

Operations Safety Office: This office provides 
Program Integration Level support to the Director, 
Utilization and Operations, in areas involving: 

• Management of SSP and payload development and 
operations safety standards (including require- 
ments definition, implementation strategy develop- 
ment, compliance assessment, and formulation of 
waiver recommendations to the Director); 

• Occupational health standards implementation and 
monitoring; 

• Review of/concurrence with Increment Hazard 
Control Plans; 
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• Certification of S&T Centers as qualified safety 
inspection sites; 

• Review of/concurrence with onboard operations 
plans and procedures relative to compliance with 
approved safety standards, including those relating 
to crew safe haven provisions; 

• SSP interface with the NASA Office of Safety, 
Reliability, Maintainability, and Quality Assur- 
ance; 

• Coordination of the SSP Program Safety Review 
Board (PSRB) schedules, agendas, and minutes. 
(The PSRB is chaired by the aforementioned SRM & 
QA Office); 

• SSP interface with the Office of Space Flight 
relative to matters involving Station crew rescue; 

• STS/SSP representation at NASA safety reviews; 
and 

• Provide chairpersons for the Systems Safety Panel 
and the Payload Safety Panel. 

Utilization and Operations Integration Office: 

This office provides support to the Director, Utilization 

and Operations, in areas including: 

• Centralized management of overall space 
operations, space operations support, and logistics 
operations support across participating NASA and 
international partner centers of expertise; 

• Configuration control of the Mission Requirements 
Data Base , containing technical systems and opera- 
tions data on each payload recommended by the 
SSUB and accepted by the SSP for flight; 

• Coordination of the acquisition of appropriate 
user/space systems data from within the various 
NASA and partner support centers to complete the 
required Payload Integration Plan (PIP) Annex- 
type documentation for each accepted user's 
payload; 

• Development of payload increment manifest 
recommendations and coordination assessments 
with other Program and institutional-level organi- 
zations; 

• Development of Station and platform Tactical 
Operations Plans; 

• Support development of Station Increment Hazard 
Control Plans; 

• Coordination of the development, planning and 
analysis of integrated logistics requirements; 

• Provision of chairpersons as required to support the 
international Systems Control Panel (SCP) and 
Utilization Control Panel (UCP) functions; and 

• Configuration control of the various planning data 
bases used to support tactical and execute-level 
space operations, space operations support and 
logistics operations support planning. 


User Accommodations Integration Office: This 
office provides support to the Director, Utilization and 
Operations, in the area of user integration into the 
Program. The office provides a cadre of Payload 
Accommodation Managers (PAM's), one to be assigned 
to each user accepted by NASA for participation in the 
SSP. The PAM's primary responsibility is to serve as 
the user's advocate to the Program. PAMs will also 
support the Systems Engineering and Integration 
Office (the SSP agent for transportation system 
Program interface) relative to payload PIP require- 
ments on/from the affected transportation system. 
Additionally, this office will support the Utilization 
and Operations Development Division in development 
of SSP marketing materials and in analysis of Consol- 
idated Utilization Plan data. 


Systems Engineering and Integration Office: This 
office provides engineering integration support to the 
Director, Utilization and Operations, in the centralized 
management of space systems sustaining engineering 
across the various NASA and international partner 
development centers. The office orchestrates the 
baseline systems configuration control process for the 
Director including: 

• Coordination of Architectural Control Documents 
and Baseline Configuration Documents maintained 
by the assigned development centers; 

• Review and classification of baseline systems 
modification requests and coordination of related 
engineering analyses; 

• Maintenance of integrated systems performance 
models and data bases; and 

• Management and control of an integrated space 
systems maintenance plan. 


In addition to these configuration control functions, the 

office also: 

• Provides support to the Program Policy Level 
utilization, operations and evolutionary planning 
functions; 

• Serves as the Program interface to the NASA 
Development Organization (external to Office Of 
Space Station Operations); 

• Manages and controls overall SSIS/SSE/TMIS 
architecture and space/ground systems interface 
requirements; 

• Manages and controls the NASCOM/SN/PSCN and 
TDRSS program interface requirements (excluding 
network scheduling which is integrated by the 
Utilization and Operations Integration Office); 

• Manages and controls real-time data processing 
(level zero) and distribution requirements for space 
and user systems; 
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• Manages and controls implementation plans and 
schedules regarding the eventual centralization of 
sustaining engineering functions at KSC; 58 and 

• Serves as the Program interface to the various 
transportation system program(s) relative to 
provision and coordination of all space and user 
systems PIP, Annex, and ICD data required of the 
SSP by the affected transportation systems 
programs. 

(3) Program Execution Functions (NASA Field 
Centers): 

Manned Base User Operations Office (MSFC): 
This office coordinates MSFC manned base space 
operations Program support activities in the principal 
area of user Program Execution Level operations 
planning and real-time support. In addition, the office 
provides ongoing support to the Headquarters Utili- 
zation and Operations Integration Office in performing 
international Payload Operations Integration Center 
(POIC) activities at MSFC. This support may routinely 
include coordination and statusing of the following 
POIC activities: 

• Support to the various NASA codes and inter- 
national partner organizations relative to payload 
operations feasibility assessments; 

• Preflight and real-time accommodation of Space 
Station Users Working Group (SSUWG) and Inves- 
tigators Working Group (IWG) personnel as 
required to support tactical-level utilization 
operations planning and perform execution-level 
utilization operations planning; 

• Performance of payload-to-manned base operations 
integration and analyses; 

• Acquisition of user operations requirements and 
development of associated PIP Annexes; 

• Support to user development of ground and onboard 
payload operations procedures; 

• Coordination of part-task and integrated payload 
operations crew training in the MSFC Payload 
Training Integration Facility (PTIF); 

• Interface with the JSC Space Station Support 
Center (SSSC) relative to acquisition of space 
systems resource templates and concurrence on 
matters of crew safety; 

• Coordination of Program payload servicing support 
requirements and analyses; 

• Consistent with the Tactical Operations Plan, 
development of integrated user operations timelines 
at the flight increment level; 

• Support to SSSC development of the Increment 
Hazard Control Plan; 


• Real-time support to the onboard crew including 
monitor ing of critical payload and user support 
equipment data; 

• Support to payload operations replanning and 
contingency operations; and 

• Coordination of network scheduling relative to 
payload data acquisition and distribution. 

Additionally, this office will coordinate the mainte- 
nance, operation and sustaining engineering for all 
MSFC facilities and equipment supporting POIC 
operations (including Technical Management and 
Information System [TMIS] equipment). This includes 
performance and trends analysis, design engineering, 
engineering integration and verification, support 
systems configuration management, maintenance and 
operations (M&O) procedures development and person- 
nel training, verification and control, implementation 
schedules development, and performance of M&O 
functions. 

Platform Operations Office (GSFC): This office 
coordinates GSFC space operations Program support 
activities involving U.S. polar and co-orbiting plat- 
forms Program Execution Level operations planning 
and real-time support. It provides ongoing support to 
the Headquarters Utilization and Operations Integra- 
tion Office in performing payload Platform Support 
Center (PSC) activities at GSFC. This support may 
routinely include coordination and statusing of the 
following PSC activities: 

• Support to the various NASA codes relative to 
payload operations feasibility assessments; 

• Preflight and real-time accommodation of Space 
Station Users Working Group (SSUWG) and 
Investigators Working Group (IWG) personnel as 
required to support Program Integration Level 
utilization operations planning and perform 
Program Execution Level utilization operations 
planning; 

• Performance of payload-to-platform operations inte- 
gration and analyses; 

• Acquisition of user operations requirements and 
development of associated PIP Annexes; 

• Support to user development of ground operations 
procedures 

• Development, validation and configuration control 
of platform operations and servicing procedures; 

• Consistent with the Tactical Operations Plan, 
development of integrated platform operations 
Execute Plans; 

• Provision of support to STS and manned base crew 
training in platform servicing techniques; 


S8 It is an SSOTF recommendation to consolidate all space systems sustaining engineering at KSC following the stabilization of orbital 
systems operations performance and achievement of a high, degree of overall Program maturity. 
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• As required to support STS or Manned Base 
servicing operations, provision of real-time support 
to the onboard crew including management and 
control of hazardous commands; 

• Monitoring of critical platform systems and user 
systems data; 

• Support to payload operations replanning and 
contingency operations; 

• Coordination of network scheduling relative to 
platform and user systems data acquisition and 
distribution; and 

• Ground operator training. 

Additionally, this office will coordinate the main- 
tenance, operation and sustaining engineering for all 
GSFC facilities and equipment supporting PSC 
operations (including TMIS equipment). This includes 
performance and trends analysis, design engineering, 
engineering integration and verification, support 
systems configuration management, M&O procedures 
development and personnel training, verification and 
control, implementation schedules development, and 
performance of M&O functions. 


Manned Base Systems Operations Office (JSC): 
This office coordinates JSC space operations Program 
support activities involving Manned Base Program 
Execution Level operations planning and integration, 
flight crew interface with Manned Base space and user 
systems, flight crew safety and health considerations, 
and flight crew training. It provides ongoing support to 
the Headquarters Utilization and Operations Inte- 
gration Office in performing Space Station Support 
Center (SSSC) activities at JSC as well as activities 
involving flight crew training at JSC and other NASA 
and international partner centers. This support may 
routinely include coordination and statusing of the 
following SSSC activities: 

• Support to payload operations feasibility assess- 
ments and analyses, especially with regards to 
onboard safety; 

• Support to Manned Base manifest assessments; 

• Support to Program Integration Level operations 
and maintenance planning and performance of 
Program Execution Level space systems operations 
and maintenance planning; 

• Interface with the POIC relative to acquisition of 
user operations requirements and concur in matters 
of payload operations safety; 

• Performance of integrated user and space systems 
operations execution planning; 

• Performance of space systems operations and per- 
formance analyses; 

• Development, validation and configuration control 
of space systems operations procedures and flight 
techniques; 


This office will also coordinate the planning and 
execution of all Manned Base flight crew and 
supporting ground operator space systems training 
activities as distributed across the Program (See 
training discussion in Section IV.H.) and ensure that 
the various simulators and trainers are maintained in 
an appropriate configuration. Additionally, it will 
serve as the requirements focal point for flight crew 
interface with space and user systems. As such, it will 
advocate and administer standards relating to systems 
design as well as those which facilitate safe and 
effective operations. Finally, this office will coordinate 
the maintenance, operation and sustaining engineer- 
ing for all JSC facilities and equipment supporting 
SSSC and crew training operations (including TMIS 
equipment). This includes performance and trends 
analysis, design engineering, engineering integration 
and verification, support systems configuration 
management, M&O procedures development and 
personnel training, verification and control, implemen- 
tation schedules development, and performance of 
M&O functions. 


Pre and Post Flight Operations Office (KSC): This 
office coordinates KSC manned base and platforms 
space operations Program support activities in launch 
site processing integration of space-bound cargo. It 
provides ongoing support to the Headquarters Utili- 
zation and Operations Integration Office in performing 
Space Station Processing Facility activities at KSC. 
This support may routinely include coordination and 
statusing of the following space systems and user 
systems integration activities: 

• Development of cargo processing schedules, flow 
templates and operating plans; 

• Development, validation and configuration control 
of processing standards and procedures; 

• Transportation system launch site interface; 

• User launch site interface; 

• International partner launch site interface; 

• Attached payload interface testing and verification; 

• Support to space systems on-orbit maintenance 
analyses; 

• Consistent with the Tactical Operations Plan, 
development of the various timeline, flight rule, and 
safety related increment execution documentation 
including the Increment Hazard Control Plan; 

• Provision of real-time support to the onboard crew 
including management and control of hazardous 
commands and monitoring of critical space systems 
and user systems data; 

• Support to Manned Base operations replanning and 
contingency operations; and 

• Coordination of network scheduling relative to 
space systems data acquisition and distribution. 
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• Experiment-to-rack interface testing and verifica- 
tion (also performed at Science and Technology 
Centers); 

• Rack-to-element interface testing, verification and 
flight certification; 

• ORU-to-element interface testing, verification and 
flight certification; 

• Postflight cargo deintegration; 

• Hardware recertification for flight; 

• Coordination of late pad access and early landing 
site retrieval requirements; and 

• Ground personnel training. 

Additionally, this office will coordinate the 
maintenance, operation and sustaining engineering for 
all KSC facilities and equipment supporting cargo 
processing operations (including TMIS equipment). 
This includes performance and trends analysis, design 
engineering, engineering integration and verification, 
support systems configuration management, M&O 
procedures development and personnel training, 
verification and control, implementation schedules 
development, and performance of M&O functions. 

Logistics Operations Office (KSC): This office 
coordinates KSC Program support activities in the 
principal area of Integrated Logistics System (ILS) 
services for space-bound cargo. It provides ongoing 
support to the Headquarters Utilization and Opera- 
tions Integration Office in performing Logistics 
Operations Center activities at KSC. This support may 
routinely include coordination and statusing of the 
following space systems and user systems logistics 
integration activities: 

• Coordination of ongoing ILS analyses by MSFC 
(part of MSFC’s space systems sustaining engineer- 
ing function); 

• ORU spares procurement, repair and inventory 
management, and supply support; 

• Development, validation and configuration control 
of ILS standards and procedures; 

• Ground transportation and handling of cargo 
elements and components including postflight dis- 
tribution, following space transportation system 
deintegration; 

• ILS personnel training; 

• Ground support equipment acquisition; 

• Space and user systems mass and volume data base 
management and control; 

• Resupply and return manifest development, 
management and control for Program logistics 
carriers; and, 

• Configuration management of ORU, crew systems, 
and user systems onboard stowage. 


Additionally, this office will coordinate the mainte- 
nance, operation and sustaining engineering for all 
facilities and equipment supporting Logistics Opera- 
tions Center and ILS operations (including TMIS 
equipment). This includes performance and trends 
analysis, design engineering, engineering integration 
and verification, support systems configuration 
management, M&O procedures development and 
personnel training, verification and control, implemen- 
tation schedules development, and performance of 
M&O functions. 


Space Systems Sustaining Engineering Offices 
(HQS, MSFC, JSC, GSFC, LeRC, KSC, Canada, 
ESA, Japan): Each NASA and international partner 
center’s office coordinates the ongoing sustaining engi- 
neering associated with its assigned space systems. 
(See Table EI-8.) for the manned base and platforms. 
In performing their sustaining engineering functions, 
each office provides ongoing support to the Head- 
quarters Systems Engineering and Integration Office. 
This support may routinely include coordination and 
statusing of the following space systems sustaining 
engineering activities: 

• Systems performance and trends analysis; 

• Design engineering (including appropriate inter- 
face with the Development organization external to 
the Office of Space Station Operations); 

• Engineering integration and verification; 

• System configuration management; 

• Definition of requirements for delegated space 
systems maintenance; 

• Technical systems operations procedures develop- 
ment and validation; 

• Support to the Headquarters configuration control 
process; and, 

• Systems upgrade and maintenance schedules 
development. 

Additionally, the KSC Office will coordinate the 
development of space systems ORU manifests, manage 
any launch site ORU maintenance and modifications, 
develop and manage generic sustaining engineering 
standards and processes, and develop and manage a 
configuration data base on each space system and 
subsystem ORU. Finally each office will coordinate the 
maintenance, operation and sustaining engineering for 
all supporting ground facilities and equipment 
(including TMES interfaces) in much the same manner 
as it supports its space systems sustaining engineering 
functions. 


IILC.2.b. Development Phase 

This section describes the modifications to the Mature 
Operations Organization necessary to meet the 
requirements of the Development Phase. This 
structure is designed to effectively manage and control 
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RESPONSIBLE 

CENTER 


CATEGORY 



AREA OF RESPONSIBILITY 


Integration of distributed sustaining engineering activities 
Technical Documentation Configuration Control 
e Integrated Elements 
e Integrated Space Systems 
e Sustaining Engineering Standards 

Coordination of baseline space systems and GFE support systems configuration 
control process 

Integrated maintenance data base control 

Development, management and control of an integrated space systems maintenance 
plan 

Development and implementation (following Program maturity) of a sustaining 
engineering consolidation plan 


Onboard space systems as follows: 
e Structures 

e Core Modules 

• Racks 

e Logistics Modules 
e Connect/Interconnect Apparatus 

• Systems 

e Environmental Control and Life Support (End-To-End System) 
e Thermal (Internal System) 

• Communication and Tracking (Internal System) 

• Data Management (Internal System) 

• Power Management and Distribution (Internal System) 
e Outfitting 

• U.S. Laboratory Module 
e Habitation Module 

e Logistics Module 
IntegratedLogistics System 
Orbital Maneuvering vehicle (OMV) 
e OMV-To- Mobile Servicing Center (MSCS) 
e OMV-To-Station/Platform Systems 

• OMV-To-Payload Systems 


Onboard space systems as follows 

• Structures 

• Truss 

• STS Interface/Berthing Mechanism 

• Mobile Transporter 
e Airlocks 

• Nodes 
e Systems 

• Data Management 

e Communications and Tracking 
e Guidance, Navigation and Control 
e Thermal Control System 

• Propulsion 

• EVA Systems 

• Resource Integration 
e Crew 

Pressurized volume payloads-to-Station 


Platform Structures and Systems (Except Power) 
Servicing Facility 

Attached Payload Accommodations 
Servicing Tools 

Flight Telerobotic Servicer (FTS) 

Payloads-To-FTS 
Attached Payloads-To-Station 
Payloads to servicing facility 
Payloads-To-U.S. Platform 


Onboard Space Systems As Follows: 

• Photo Voltaic Module 
e Solar Dynamics Module 
e Station Power Management and Distribution 
e platform Power 


Launch site maintenance and modifications to space systems ORU's 
Engineering analyses of logistics operations ana prelaunch/postlanding operations 
processes in support of effective handling of space systems ORU's and supporting 
GFE 

ORU up/down manifest development and coordination with the transportation 
system organization 

As a delegated task from the program integration organization, development of 
generic standards for space systems sustaining engineering for use by all distributed 

Development and management of a configuration status and maintenance history 
data base for each space system ORU 


MSCS 

MSCS-To-Payload 


Columbus lab and associated space system 
Pressurized Volume Payloads-To-Columbus Module 


Japanese Experiment Module/Exposed Facility/Experiment Logistics Module and 
associated space systems 

Pressurized volume pay(oads-to- Japanese Experiment Module/Exposed 
Facility /Experiment Logistics Module 


A = Maintenance Engineering Responsibility 
B = Design Engineering Responsibility 
C a Payload Integration Responsibility 
D = Sustaining Engineering Integration Responsibility 

Reference section III.B.2, Engineering Support Operations, for category definitions. 


Table III-8 Space Systems Sustaining Engineering Responsibilities 
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the development of a diverse and user-oriented 
Program operations capability. Further, it supports 
the complex assembly and verification process and 
allows for special Program emphasis in areas where 
operations advocacy at a visible organizational level is 
important during development. Finally, it facilitates 
gradual "organizational transition" to the structure 
recommended for the Mature Operations Phase as the 
Station elements are assembled and verified. 


Where no specific mention is made below of organiza- 
tional elements appearing in the Transition Operations 
Organization diagram (see again Figure HI-26), the 
reader should assume that the affected element's 
operational support functions are essentially the same 
as defined for Mature Operations. Of course, there will 
be a slant towards development of the capability to 
perform those functions rather than of routine mature 
operations support: 

(1) Program Policy Functions (NASA 
Headquarters): 

The SSOTF assumed that the existing Office of Space 
Station would create and provide Program Policy level 
management for the Transition Operations Organiza- 
tion. Strategic planning functions for the Development 


Phase are essentially the same as for the Mature 
Operations Phase, but emphasize the development of 
an initial utilization and operations capability and 
defining discipline-generic user requirements (as 
opposed to defining specific user marketing strategies, 
evolutionary planning, etc.). The various NASA and 
partner operations agreements will be established 
through this level of the Transition Organization. As 
currently defined within the Office of Space Station 
(Figure HI-27), the operations-related organizational 
elements (including user-oriented elements) appear 
adequate to support Program Policy level transition 
planning at this stage of Program development. 
However, as noted above, the SSOTF believes that the 
Operations Organization should be separated from the 
Space Station Development Organization during the 
Development Phase. 

(2) Program Integration Functions (NASA 
Headquarters): 

The Increment Change Management Office will not 
be required in the early Transition Organization; 
however, this office must be in place and organized two 
years before the first element launch to oversee 
detailed operations planning unique to each assembly 
and verification mission (analogous to a mature 
operations "increment "). 



Figure III-27 NASA Headquarters 

ORIGINAL PAGE Office Of Space Station Organization (Code S) 
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The Space Systems Development Support Office 
will serve as liaison to the space systems Development 
Organization. It will be responsible for ensuring that 
the Development Organization fully integrates opera- 
tional requirements into their Space Station systems 
engineering activities. It is recommended that the 
Development Organization have an analogous office 
(depicted in Figure III-26 as the Space Systems 
Operations Requirements Integration Office), 
specifically responsible for the integration of these 
requirements into space systems designs. 

During the Development Phase, there will be no 
dedicated Operations Safety Organization at the 
Program Integration Level. The Office of Space 
Station has established the appropriate interfaces with 
the headquarters Office of Safety, Reliability, Main- 
tainability and Quality Assurance (Code Q) to ensure 
safe systems design during the Development Phase. 
Furthermore, there will not be enough payload systems 
design and operations details available to justify a 
dedicated payload safety integration office. Finally, it 
will be some time before there are dedicated ground 
facilities operating on behalf of the Space Station 
Program. (Their development is to be certified safe by 
their respective institutional organizations.) As 
specific payloads are selected and funded for partici- 
pation in the Program, and as support facilities are 
developed and enter their operations capability 
certification and assembly operations support stage, a 
dedicated safety operations integration function will 
certainly be justified. 

The utilization and operations functions have not yet 
been combined in this Transition Organization concept. 
The SSOTF judged that at least until the Space Station 
Users Board, the Utilization Operations Panel and the 
Space Station Users Working Group are formed and 
their respective functions assumed, the Program 
should continue to organizationally provide for specific 
user advocacy. Such advocacy ensures that all avenues 
for user access to the Program are fully supported, and 
there is continued objective critique of overall systems 
design and operations capability development to 
support the NASA goal of providing a user-friendly 
Station Program. Hence, the User Operations Integra- 
tion Office is kept separate 

Additionally, since it will be some time before 
significant numbers of specific users are selected and 
funded for Program participation (and hence, few 
requirements for dedicated Payload Accommodation 
Managers), there is not yet a requirement for a 
dedicated user accommodations function within the 
Transition Organization. Any early requirements for 
user integration will be handled by the User 
Operations Integration Office. 

The SSOTF judged that the scope and complexity of 
activities associated with development of an integrated 
logistics capability warranted a separate integration 
office at NASA Headquarters. 

The long term supportability of the Station Program 
will be determined in large part by the success of the 
logistics integration activities during the Development 
Phase. One of the key determinants of life-cycle-cost is 
the systematic implementation of Program policies 


regarding commonality, reliability and maintainabil- 
ity. The efforts of a Program Integration level office 
will be required to maintain adequate development 
funding to define and implement these policies across 
the Work Packages and to oversee the development of 
the information systems and management infra- 
structure necessary for mature logistics operations. 
Hence, the Transition Organization includes a Ground 
Operations Integration Office and Logistics Operations 
Integration Office as organizational elements at the 
Program Integration level. 

Likewise, the task of focusing the operations require- 
ments regarding overall architectural design and 
implementation of the Space Station Information 
System (SSIS), with its numerous ground and onboard 
components, is large enough in scope to justify a 
dedicated Program integration function. Hence, the 
Transition Organization includes a Data Systems 
Operations Integration Office as an organizational 
element. Additional responsibilities of this office are to 
integrate the ground operations requirements 
associated with the development of the Software 
Support Environment (SSE) and the Technical 
Management and Information System (TMIS), each 
required to complement the end-to-end SSIS network 
operations. 

During the early-to-mid Development Phase, there is 
no requirement for a dedicated space systems 
sustaining engineering integration function since the 
various elements and systems are still the 
responsibility of the Development Organization and its 
associated work packages and prime contractors. 
However, as the Space Station is gradually assembled 
and its components verified, the work package 
development centers will transition their respective 
space systems' sustaining engineering responsibilities 
to the Operations Organization. Therefore, a systems 
engineering and integration function must be in place 
at Headquarters in time to effect a smooth handover. 

(3) Program Execution Functions (NASA Field 
Centers): 

With the exception of the Engineering Support 
Centers, all field center organizations will support the 
same operational areas during the Development Phase 
as they do during the Mature Operations Phase. 
However, functional emphasis will vary over the course 
of the transition period, from support facilities/systems 
requirements and implementation plans development; 
to construction, outfitting and certification of the 
facilities/systems; to direct support of Space Station 
assembly and operations verification. 

The MSFC, JSC, and GSFC operations capability 
development field offices depicted on Figure ni-23 
provide routine Program support through the 
Headquarters Space Operations Integration Office; the 
KSC Pre and Post Flight Operations Capability 
Development Office provides routine support through 
the Headquarters Ground Operations Integration 
Office and the KSC Logistics Operations Capability 
Development Office provides routine support through 
the Headquarters Logistics Operations Integration 
Office. 
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As discussed earlier, the Engineering Support 
Centers responsible for space systems sustaining 
engineering during the Mature Operations Phase will 
not become a part of the Operations organization until 
after each center’s delegated space systems have been 
delivered to orbit and operationally verified. At that 
time, the responsibility for sustaining engineering will 
be handed over to the Engineering Support Center at 
that field center. 59 


III.D. THE USER INTEGRATION SCENARIO: 
ILLUSTRATING THE OPERATIONS 
FRAMEWORK 

As part of the final concept verification effort, the Task 
Force developed a scenario illustrating the process by 
which a user’s payload and operations are integrated 
into the Space Station Program. The effort resulted in 
detailed user integration ’’flow charts” (enclosed 
separately) demonstrating the activities and mile- 
stones involved in the process, and a narrative of this 
flow. 

There were several goals for this effort: (I) to assist in 
the consolidation of the concepts developed by the 
individual panels into one coherent operations concept; 
(2) to ensure that these concepts were mutually 
consistent and supportive; (3) to verify that the 
concepts provided for a consistent and complete user 
integration process; and (4) to ensure that this process 
is "user friendly" and can accommodate the divergent 
needs of users from different functional and demo- 
graphic groups. 

The scenario falls into three sections: the first section 
traces a single "generic" manned-base user through the 
user integration process. Differences in the flow for 
users with special requirements — particularly 
between "regular" and "quick is beautiful" users - are 
pointed out where applicable. The second section 
traces the development of a new platform; the third 
section, the addition of new payloads to an existing 
platform. The scenario was assumed to take place 
during the Mature Operations Phase of the Space 
Station Program (SSP). It is assumed that a "normal” 
crew complement is available to handle payloads, and 
that no evolutionary changes to the Station are 
planned for this time. 

III.D.L Manned Base Operations Flow 

Summary 

The scenario begins with the distribution of Space 
Station resources to the international Space Station 
partners, then outlines the process by which U.S. 
resources are distributed among the major user groups. 
(See Figure HI-28 for a summary version of the user 
integration flow.) From this point on, the scenario 
traces a single generic user through payload selection, 
definition, development, planning, operations and post- 
operations activities. 


Different payload sponsors will vary as to their payload 
selection procedures; however, this process begins 
when a sponsor (usually a NASA office) solicits investi- 
gators to propose payloads to accomplish the sponsor’s 
goals within the sponsor’s resource allocation. The 
user submits a proposal, which is reviewed by the 
sponsor and, typically, by a peer review group. Having 
passed this review, the sponsor provides a list of 
candidates via the Space Station User Board (SSUB) to 
the Office of Space Station Operations (OSSO), which 
performs a feasibility assessment to ensure that the 
payload can be accommodated on the Station. The 
results of this assessment are provided to the sponsor. 
Based on the peer review and the feasibility assess- 
ment, the sponsor selects users. These users’ requests 
for flight are submitted to the SSUB for coordination 
into the five-year Consolidated Utilization Plan (CUP). 


At this point, the user is ready to begin payload 
definition and design work. At several points during 
this process, OSSO conducts reviews (including a 
multiple-phase safety review) to support planning 
efforts and to ensure compliance with Station stan- 
dards. These reviews support the payload-to- Station 
integration process, providing data for the Interface 
Control Documents (ICDs), Payload Integration Plans 
(PIPs), and the Annexes to the PIPs. 60 At about two 
years before launch, typically around the time of 
payload Preliminary Design Review (PDR), the user’s 
payload is entered into the Tactical Operations Plan, 
assigning the payload to a specific flight increment. 
The user completes payload definition, participates in 
operations planning efforts, and conducts or supports 
crew training and simulation efforts. 


Approximately six months before launch, the payload 
is delivered to the Space Station Program for final 
integration, testing and verification prior to launch. It 
is launched by the Office of Space Flight and integrated 
into the Station by the Space Station crew. The user 
participates in on-orbit check-out and commences user 
operations. As long as the payload is onboard the 
Station, the user participates in daily planning (called 
"replanning") with other users, and operates and 
monitors his payload and crew operations relating to it. 
Onboard activities may be performed by a user- 
sponsored astronaut who has trained and operates as a 
member of the crew. When his operations are 
completed, the user shuts down the payload, the crew 
deintegrates it, and it is returned to earth. The user 
retrieves his hardware and/or any other materials or 
data, then completes his participation in the program 
by debriefing the offices that have been involved in 
accommodating him throughout the user integration 
process. 


The following sections illustrate the manned base user 
flow in greater detail, and refer to the complete 
flowchart associated with this volume. 


59 The ESCs may very well consist of the same personnel reporting to a different parent organization. 

60 These names refer to documents used in the STS program; the STS names are used here to indicate that the Station documentation 
will be equivalent in nature and purpose. The names may or may not be the same. 
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Initial Distribution of Resources to Partners and 
Disciplines 

Before specific users can be selected, Station resources 
must be distributed among the various partners and 
user sponsors. The Multilateral Control Board (MCB) 
will divide among the partners the total Station 
resources available to users (as opposed to those 
required to maintain the Station and crew). Based on 
information provided by the OSSO Utilization and 
Operations Development Division (UODD), the MCB’s 
Systems Operations Panel (SOP) will provide the MCB 
with a projection of Station resources available to users 
over the coming five years. The MCB will review this 
projection in light of the MOU agreements, and notify 
the partners of the resources available to each . 61 

Each partner will be free to select users as it sees fit 
within the resource envelope allotted to it. In the U.S., 
a Space Station User Board (SSUB), consisting of 
representatives of each class of user, will divide the 
U.S. allocation among the disciplines that use the 
Station. Currently, these classes are expected to 
include science and applications research, technology 
development, cooperative commercial (i.e., those 
performing R&D activities under cooperative agree- 
ments with NASA), commercial reimbursable users 
(i.e., those who will pay their own way on the Station), 
and other non-NASA government agencies - primarily 
NOAA and DOD. These user class allocations will be 
reviewed and reworked by the SSUB as new types of 
users emerge. 

With the exception of the non-NASA government 
users, each user class will be assigned a sponsor 
Program Office within NASA. This sponsor will 
represent that user class on the SSUB, and will be free 
to distribute its resource allocation as it sees fit to users 
within that class. For space science or application 
users, the sponsor will be Code E, the Office of Space 
Science and Applications. The Office of Aeronautics 
and Space Technology, Code R, will sponsor technology 
development users. Commercial cooperative users will 
be sponsored by Code I, the Office of Commercial 
Programs. Reimbursable commercial users will be the 
responsibility of the Office of Space Station Operations 
(OSSO) itself, unless they prefer to come through one of 
the other codes. Other government agencies (e.g., 
DOD and NOAA) will represent themselves on the 
SSUB. 

Marketing/User Development 

The UODD will perform a general Program marketing 
function: conducting conferences, publishing articles 
and brochures, and otherwise alerting the potential 
user communities of the Program’s availability and 
capabilities. However, the various user sponsors will 
bear primary responsibility for marketing to users 


within their assigned classes. After they have been 
notified of their resource allocation, the sponsor codes 
will obtain budget authority for new payloads or 
programs utilizing the Station . 62 The sponsors will 
then solicit investigators via announcements of oppor- 
tunity (AOs) or other means. These solicitations could 
be proposed or handled by Science and Technology 
(S&T) Centers, which have developed expertise in a 
particular area of Space Station utilization (e.g., 
materials or life sciences ). 63 UODD will assist the 
sponsors by providing specific cost and technical 
information, and will develop standardized forms for 
user/ Station agreements. 

A commercial reimbursable user (i.e., whose payload 
will not be funded by NASA) may learn of oppor- 
tunities on the Station through UODD, Office of 
Commercial Programs or other sponsor outreach activi- 
ties (conferences, target visits, advertising, articles in 
the trade and general press); through an existing 
contact within a NASA office; or may contact the Office 
of Space Station Operations at his own initiative. If the 
user does not initially contact the appropriate sponsor, 
he will be referred to one for further information. 

Contracts with and support to DOD, NOAA or other 
non-NASA government users will be handled by 
UODD. 


Payload Selection and Inclusion in the CUP 

Once a user has indicated a preliminary interest in the 
Program, his NASA sponsor will encourage him to 
submit a formal proposal. If necessary, the UODD will 
assist him by providing Station information and 
requirements. His proposal will then undergo a series 
of reviews to determine its compatibility with the 
sponsor’s goals; with the goals, capabilities and 
constraints of the Space Station Program; and with the 
resource allocations laid out by the SSUB and MCB. 


The user’s proposal will first be reviewed by the 
sponsor office to ensure that it meets the goals of the 
solicitation to which it responds. Reimbursable users 
will be reviewed only to ensure that the payload will 
not contravene any limitations placed on Space Station 
activities (by treaty, MOU or U.S. policy, or by safety 
constraints). The SSUB will review the payloads that 
have passed this milestone, and provide candidate 
payload information to the UOIO. The UOIO will use 
this information to perform a feasibility assessment to 
ensure the payload’s compatibility with Station 
systems and operations. Institutional operations 
offices will support this assessment as necessary to 
verify that the candidate payload will meet crew 
interface and safety standards and can be supported by 
the logistics, transportation and information systems. 


61 The SOP and UOP are internationally staffed and provided for in the MOUs between the U.S. and its partners. 

62 The relevant NASA user sponsors may subdivide their resource allocations into sub-blocks allotted to their component disciplines 
(e.g., micro-gravity, astrophysics, robotics, structures , etc.) and request funding based on these sub -allotments. 

63 The S&T Centers will be established and funded by the Codes and other sponsors, and will be located at NASA or partner field centers 
(or elsewhere) to support and take advantage of existing centers of expertise. 
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The SSUB will then provide the results of the 
feasibility review and preliminary user definition 
activities back to the sponsors. The Codes then 
formally select the payloads they plan to sponsor. 
Following selection, the user prepares a Request for 
Flight (RFF), which is similar to the STS Form 1628. 64 
The RFF will outline the user's anticipated demand for 
Station resources, the location of the payload on the 
Station, the desired flight date(s), and payload priority. 
For commercial users, the RFF will also cover 
insurance provisions, the involvement of a Payload 
Scientist on board the Station, and any other issues 
which must be considered to permit planning and 
pricing of the activities. The sponsor provides the user 
with a "best efforts" commitment to the costs which the 
user must pay for access to the Station. 65 The user will 
also review the restrictions and requirements that the 
SSP will impose on his payload and activities. 

The SSUB examines the total payload complement 
selected by each sponsor to ensure that the total 
resource requirements do not exceed the resources 
allocated to that sponsor's class. 66 If all sponsors' 
selections are within their allotments, the SSUB 
forwards the combined complements to the User Opera- 
tions Panel for consolidation with payloads approved 
by the other Space Station Partners. 67 With the 
support of the UODD, the UOP will combine all of the 
selected payloads into the CUP and forward it to the 
MCB for final approval. The CUP will list all of the 
major utilization and operations activities planned for 
the Station over the next five years, and will assign 
payloads to a particular year and quarter. (It will not 
assign the user to a particular flight increment.) The 
CUP will also assign each payload to a particular 
transportation system (i.e., Shuttle or ELV). The 
Associate Administrator for Space Station Operations 
will sign the CUP (acting in his role as Chairman of the 
MCB), and sign all of the Requests for Flight (U.S. and 
international), thereby accepting all payloads into the 
program. He will then forward the CUP to the UOIO 
for implementation. 


At this point, all users on the CUP will have received a 
commitment to fly on the Space Station and to a 
calendar quarter, although they will not have received 
a commitment to a specific date. 


Initial Assessment and Development Planning 

When the CUP is released, the user will initiate 
payload development activity and will become a 
member of the Space Station Users Working Group 
(SSUWG), which will represent the interests of all the 
users in the program. 

At the same time, the User Accommodations 
Integration Office will assign the user a Payload 
Accommodation Manager (PAM), who will assist the 
user in completing all SSP assessments and docu- 
mentation, and in meeting the requirements imposed 
by the Program and by the transportation system that 
will carry his payload. The PAM will work with the 
user to develop a Payload Integration Plan (PIP) and 
annexes specifying the user's requirements and 
responsibilities for all phases of the program. The 
PAM will be the user's single point of contact with the 
Space Station Program, as well as with the transpor- 
tation and data systems offices, for the remainder of his 
participation in the program with this payload. 
Although the user will be required to satisfy the 
requirements of many offices within the Program and 
will be at liberty to contact these other offices if he so 
desires, he may direct all his inquiries through the 
PAM. Similarly, all requests from the SSP to the user 
will be routed through the PAM. 68 This arrangement 
will minimize the confusion that would be caused by 
multiple user-program interfaces. 

The PAM's first responsibility will be to arrange for an 
indoctrination meeting which will outline SSP 
requirements and reviews. He will also work with the 
user and the sponsor to assemble a development plan 
for the user's payload and the associated operations 
procedures and ground facilities. The PAM will 
monitor the user's payload development to ensure 
compliance with standards and with schedules. 

The user's sponsor may also assign an experiment 
development engineer (possibly from an S&T Center) 
to assist the investigator in designing and developing 
his payload. In this case, the PAM would work with 
both the user and his engineer. Thus, the S&T Center, 
other sponsor organizations, the Payload Operations 
Integration Center (POIC) and the PAM may all assist 
the user in developing his payload, operations plans 


64 Formerly a Form 100. 

66 This commitment will be based on information provided to the sponsor by the OSSO User Operations Development Division. It is 
important that UODD provide the sponsor codes with sufficiently detailed documentation regarding operating costs and pricing policy to 
enable the sponsor to negotiate this commitment. 

66 If the sponsor's total payload complement exceeds that sponsor's allotment, the SSUB will send the complement back to the sponsor for 
the sponsor to pare down. 

ti7 The international partners will solicit and select users according to their own procedures. As with U.S. payloads , however, the 
proposed payloads will undergo a feasibility assessment by the UOIO prior to submission to the UOP. 

68 Initially , all PAMs will be drawn from the element development centers, and will have particular expertise in the characteristics of the 
element where the payload is to fly. In the future, the PAM assigned to the user may be drawn from the appropriate sponsoring organization 
or S&T Center so that he will have sufficient expertise in the relevant discipline to perform both the PAM and experiment development 
engineering roles (i.e., to support the user both in developing his payload and in satisfying SSP requirements). The UAIO would be 
responsible both for ensuring that an appropriate PAM is assigned, and for training and certifying the PAMs sponsored both by OSSO and 
other NASA-sponsored offices. 
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and ground facilities. The extent of the support 
provided by the PAM and/or POIC personnel depends 
on the terms agreed to in the Request for Flight 
submitted at the beginning of the user's involvement 
with the Program. 

Integration of User’s Requirements into TOP and 
Assignment to a Flight Increment 

Approximately 24 months before flight (typically at or 
near payload PDR), the user's payload will be entered 
into a specific flight increment within the Tactical 
Operations Plan. To do this, the user must define his 
Station requirements to the point where they can be 
coordinated with those of other users. The PAM will 
arrange for a series of reviews and briefings (including 
a safety review) with all of the institutional operations 
offices involved in supporting the user's payload. 

The PAM will use the information obtained in this 
round of assessments to update the PIP and its 
Annexes. The Utilization and Operations Integration 
Office will combine the information in the user's PIP 
with requirements provided by other users, the Office 
of Space Station Operations, the Office of Space Flight, 
and the international partners to assign the payloads 
to a specific flight increment. 69 This new increment 
will be added to the Tactical Operations Plan (TOP) 
which covers all of the increments scheduled to occur 
over the next two years. 70 The TOP must be approved 
by all of the partners via the Program Operations 
Control Board (POCB), which is responsible for 
oversight of tactical operations planning. 

A user must enter the SSP planning process by this 
stage if he requires a "complete" range of Station 
resources (particularly significant crew time and/or 
power). Because of planning constraints, users 
entering the increment after this point will be 
restricted with regard to the range of payloads they can 
implement. For instance, crew specialization and 
composition is determined soon after the release of the 
TOP, and crew user training begins at approximately 
18 months before launch; as a result, major new crew 
operations cannot be added to the operations plans once 
the crew has been assigned. 

The TOP will provide "top" level data pertaining to the 
integration of payload and key Station operations 
requirements over the course of the increment. Space 
transportation systems and data systems support 
operations will also be included. Once his payload is 
included in an approved TOP, the user becomes 
involved in utilization planning for that increment. A 
Program-provided Increment Change Manager is 
assigned to lead in development of a Flight Increment 
Plan (FIP), which integrates payload and space 
systems operations requirements down to the next 
level of detail. The FTP identifies specific scheduling 
constraints, crew skills and work load, payload 
objective priorities, and specific maintenance and 
servicing requirements in order to provide the execute 
planning teams with the data they need to develop 


implementation-level plans and procedures. The 
Increment Change Manager is support by an Incre- 
ment Management Team, composed of representatives 
of operations organizations and of the PAMs who 
represent the increment users. The FIP is refined over 
a period of about six months, and is baselined 
approximately one year prior to the beginning of the 
increment. 

Based on the TOP and FIP data for an increment, the 
System Engineering and Integration Office (SE&IO), 
working closely with the assigned PAMs, will support 
the increment users by serving as Program liaison with 
the transportation and data systems services organiza- 
tions regarding the integration and accommodation of 
user requirements for transportation to and from the 
Station, and for payload data handling. In this 
capacity, the SE&IO will represent user requirements 
in planning meetings, process required Program 
interface documentation, develop associated TDRSS 
utilization plans, and coordination of up/down mani- 
fests implementation. 

The TOP, FIP and related transportation and data 
systems services integration plans and manifests will 
then be forwarded to the various operations support 
centers where increment execute planning will begin. 
Similarly, the transportation and data systems 
services organizations use the documentation to affect 
their own detailed planning. Additionally, the NASA 
Safety, Reliability, Maintainability and Quality Assur- 
ance Office will review matters of safety, particularly 
the payload operation issues reflected in the Increment 
Hazard Control Plan — a product of the increment 
execute planning process. 

Once the user has been assigned to a particular flight 
increment, he joins other Pis for that increment in an 
Investigators Working Group (IWG), which will be 
directed by an Increment Scientist. This group will 
work together to support development of the FIP, and 
to participate in operations execution planning based 
on the contents of the TOP. The IWG will consist of 
representatives from each user (or at a minimum, from 
each discipline operations center and each direct user). 
It is anticipated that many of these coordination 
activities will, in practice, be handled by the IWG’s 
Increment Scientist, PAM or other user representative 
on behalf of his users. 


Payload, Operations and Ground Facility 
Development 

In addition to developing his payload, the user needs to 
gain access to ground facilities from which to monitor 
and operate his payload as needed during flight. These 
facilities must provide all capabilities necessary to 
allow the user to perform any required teleoperations, 
and to oversee any relevant crew activity. The user 
also will be responsible for training any necessary staff 
to operate the payload from this facility, based on the 
payload's operations plan and characteristics. 


60 The UOIO also uses this information to update the Mission Requirements DataBase (MRDB). 
70 This TOP is based on a 45 -day STS revisit schedule. 
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It is anticipated that most users will be assigned to a 
Discipline Operations Center (DOC) or Regional 
Operations Center (ROC) by their sponsor or S&T 
Center. DOCs will be facilities established to support 
work in a single discipline; ROCs will support users in 
a specific geographical area. The DOC or ROC will 
coordinate the operations of its members during flight 
preparation and execution, and may make operations 
facilities available to the users. If desired, the user 
may build his own User Operations Facility (UOF) that 
will link up with the Station and be coordinated with 
other users via the DOC or ROC. Users who operate 
their payloads in or via a DOC will be referred to as 
"discipline users," while ROC users will be referred to 
as "regional users." Some users (particularly commer- 
cial proprietary users) may develop independent UOFs 
that interact with the Station directly via the POIC; 
these users will be called "direct users." 

Final Operations Assessments 

About 18 months prior to launch, the Increment 
Change Manager coordinates final operations assess- 
ments by the SSSC, the POIC, and all other offices 
involved in accommodating the payload. The user’s 
PAM and sponsor organization support this assessment 
as required. Based on all of the user's operations 
assessments and the initial planning efforts of all 
OSSO offices, an increment flight crew is assigned at 
this time. 

Integration of the User’s On-Board Operations 
into the Execution/Operations Planning Process 

Based on the FIP and on the results of his final 
operations assessment, the user will participate in the 
increment execute planning process. These execute 
plans are refined continuously until the Increment 
Operations Plan (IOP) and supporting procedures and 
data are finalized six weeks prior to the launch that 
initiates the flight increment; changes occurring after 
this time are considered a part of the "replanning" 
process which continues throughout the increment. 

To initiate the execute planning process, the SSSC will 
update the resource envelope available to users, based 
on the TOP, FIP and updated systems requirements 
estimates, and will forward this estimate to the POIC. 
The POIC will adjust the resource assignments to the 
various DOCs, ROCs and direct users, who will develop 
refined and updated operations plans. The POIC then 
develops an integrated user operations execution plan. 
After approval by the IWG, this user operations execu- 
tion plan is passed to the SSSC for verification of 
compatibility with Station systems requirements and 
for publication as part of a Preliminary Increment 
Operations Plan. If there are any conflicts between 
user requirements that cannot be resolved by the IWG, 
the POIC has the authority to resolve them. If there 
are conflicts between user and systems requirements, 
the SSSC will be responsible for resolving them. Any 
disputes that cannot be resolved within the SSSC/POIC 
must be taken to the POCB. 

This process will result in a plan which assigns the user 
a particular envelope of resources (crew time, trans- 
mission time, power, etc.) within which he is free to 
carry out his operations. If the user requires inter- 
mittent contact with his payload, he will be assigned 


particular blocks of time within which he can contact 
his payload. If he requires contact with the astronauts, 
he will be given access to a voice link as necessary. He 
can then plan his DOC, ROC or UOF activities within 
this envelope. 

Crew Training Requirements 

The user is responsible for training the Station crew 
and ground personnel in the operation and mainte- 
nance of his payload. The user will explain to the 
Station crew and ground personnel the scientific back- 
ground of the payload and the experiment objectives, 
familiarize the crew and ground personnel with the 
experiment systems, and teach the crew the operations 
plan for his payload. These activities will occur at the 
PTs site where he can draw on his own facilities in 
training the crew and ground personnel. If the user 
will be providing a Payload Scientist, this person will 
be instrumental in this training function. 

Following these sessions at the user's facility, users 
with particularly complex payload execution require- 
ments will be asked to deliver two high-fidelity copies 
of their payload and any related software to the SSP for 
use in simulation and training activities. These 
models would "migrate" as needed through the simu- 
lators. They would be used first at the high-fidelity 
simulator collocated with the POIC, then move to the 
SSSC/SSTF as the crew moves from integrated payload 
training to integrated increment training. 

The user would also undergo training provided by the 
SSP, in concert with the crew and other users. This 
training would familiarize the user with the command 
procedures for normal and contingency situations, 
teach him about the "transaction management" system 
used to ensure that user operations do not conflict with 
one another, and verify that his UOF is operational 
prior to launch. If a Payload Scientist will operate the 
payload on the Station, this individual must be trained 
in Station habitation, health maintenance, and in 
operating other crew systems (such as cameras, 
communications systems, etc.). 

Payload Integration and Logistics Operations 

Prior to launch, the user's payload must be integrated 
into experiment racks or other carriers, and the racks 
into one of the SSP logistics modules or external pallets 
(U.S. or Japanese). Payloads may be integrated into 
racks either at the S&T Center which has supported 
the user, at the launch site by the U.S. Pre and 
Postflight Operations Office, or at integration facilities 
provided by the international partners in the U.S. or 
abroad. The location of rack integration depends both 
on the terms of the PIP agreement, which sets out the 
user's relationship with an S&T Center; and on the 
location of the payload on the Station. (Payloads flying 
on international elements are integrated by the 
international partners.) 

If the user will be sending any supplies or spares along 
with his payload (or on a later increment, if the experi- 
ment continues), he will coordinate provision of these 
ancillary materials through the PAM to the Logistics 
Operations Office for incorporation into a logistics 
module. 
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The Logistics Operations Office will make storage and 
preservation facilities at the launch site available to 
the user according to terms established in the PIP 
agreement. These facilities will support users from the 
time the payloads are delivered to the launch site until 
launch. 

Prelaunch Processing 

Once the racks and other equipment have been 
integrated into the logistics module or pallet, the Space 
Station Program delivers the module and any other 
carriers to the Office of Space Flight. OSF integrates 
the module into the Shuttle or other launch vehicle, 
and is responsible for the module from that time until 
it has been off-loaded onto the Station. If the user 
requires late access to his payload after integration 
into the Shuttle or ELV (for feeding of laboratory 
specimens, handling of perishable substances, or last- 
minute loading of experiments), the SSP will arrange 
for that access via the PAM. All late access require- 
ments will be coordinated by the SSP SE&I Office with 
the Office of Space Flight. OSF is responsible for 
overseeing and executing late access requirements to 
the STS and/or ELVs. 


On-Orbit Check-out/V erification 

After the Shuttle has docked with the Station, and the 
logistics module has been unloaded, the Space Station 
crew will install the new racks and equipment. Once 
the user’s payload is in place, it must undergo an on- 
orbit check-out to ensure that it is functioning 
properly. The order in which systems and payloads are 
checked out is determined prior to launch as part of the 
increment execution planning process. From his 
operations facility, the user will issue the commands 
required to complete checkout and verification, and 
will oversee the activities of the crew. The POIC will 
integrate the user's commands with those of any other 
user, and pass them on to the SSSC for relay to the 
Station. The crew will perform any necessary onboard 
adjustments as overseen by the user and the SSSC. If 
the user desires, the crew will perform the entire 
payload check-out procedure, freeing the user from the 
responsibility for issuing checkout commands or 
overseeing onboard activities. Once the payload and 
systems checkouts have been completed, increment 
operations can begin. 

Integration of User Operations in Daily 
Replanning Process 

The Increment Operations Plan covers the entire 
period of increment operations. However, detailed 
crew integration planning is provided by the IOP only 
for the periods involving STS/ELV transfer operations 
or other activities requiring complex crew/ground 
interaction (e.g. OMV missions, complex EVAs). 
Planning for routine operations during the increment 
will be coordinated on a daily/weekly basis by the 
execute planning teams at the SSSC and POIC and 
forwarded to the onboard crew for implementation. 
Each day, the SSSC will update the POIC on the status 
of Station systems; the POIC will in turn update the 
IWG on the status of the user resource envelope. If 
there are any changes to this envelope, it is up to the 
IWG to coordinate changes to the individual user 


plans. (The IWG or representatives of the IWG will be 
located at the POIC during the operations increment to 
support this function.) Under the direction of the Incre- 
ment Scientist, user representatives will negotiate new 
resource and time envelopes and forward a modified 
consolidated plan to the POIC; the POIC will in turn 
hand the consolidated plan over to the SSSC to check 
for compatibility with Station systems replanning 
data. 

Inflight Operations 

While his payload is in orbit, the user must perform 
operations originating from his UOF, and oversee any 
actions taken by the Station crew with regard to his 
payload. He is also responsible for monitoring the 
status of his payload to ensure that it remains in safe 
operating mode. The POIC monitors Station support to 
all user operations to ensure compliance with user 
requirements. At the same time, the SSSC monitors 
systems status and ensures that user operations are 
not adversely affecting the safety or health of crew or 
Station. 

The user will receive data from his payload while it is 
operating on orbit that will allow him to determine 
whether his payload is functioning as planned, or 
whether changes in hardware, specimens or plans are 
necessary. If changes are required, he can negotiate for 
additional crew time or other resources through the 
IWG as part of the daily replanning process. 

If the user's instrument suffers a failure during flight, 
it is his responsibility to correct or coordinate 
correction of that failure unless the Station systems are 
suspected of causing the failure. The user may develop 
a payload inflight servicing plan prior to flight which 
must be performed by the crew. (This expense must be 
covered by the user.) Any changes in the user's 
operations (such as contingency operations) must be 
approved within the IWG and by the POIC/SSSC prior 
to implementation. 


Updating Requirements for Continuing 
Operations 

If the user's payload will operate for more than one 
increment, the user must forward any changes in his 
resource requirements to the Utilization and Opera- 
tions Integration Office for inclusion in the plan for the 
next increment. These changes must be approved by 
the POCB before the start of the next increment. 


Payload Shut-Down and Safing for Return 

When the user's operations have ended and the payload 
is to be returned to earth, the user is responsible for 
turning off his payload to ensure safe rack deinte- 
gration and to protect his specimens or results. As for 
payload checkout, the Increment Execute Plan will 
include a schedule for this process. The user will 
perform any ground-based commands and oversee the 
actions of the crew in dismantling the equipment. The 
POIC will integrate all user requirements; the SSSC 
will integrate these user operations with the systems 
changes necessary during an increment handover. 
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Payload Pick-Up 

Following the return of the payload to the earth, the 
user must pick up his payload and his product and/or 
data. The Pre and Postflight Operations Office will 
deliver the rack (or racks) for deintegration to 
whatever organization integrated it prior to launch: 
The Logistics Operations Office will then deliver the 
payload to the customer using the means of trans- 
portation appropriate to the equipment. If the user 
requires, the SSP will allow him to retrieve the payload 
at the STS landing site. The timing, location and 
service fees associated with the pickup, as well as the 
means of transportation, will be negotiated as part of 
the original PIP agreement or a later amendment to 
this agreement. 

User Debriefing 

When the user's operations for a given payload have 
been completed, he will undergo a debriefing involving 
his sponsor, his PAM, the Utilization and Operations 
Integration Office, the Pre and Postflight Operations 
Office and the Logistics Operations Office. This 
debriefing will be used by the SSP to improve its 
services or interfaces; by the user in planning for his 
next payload, if any; and by the sponsor in determining 
the utility of the Station in fulfilling its goals. 


Archiving of Data 

Some users (particularly science, applications and 
technology users) will want or be required to archive 
data to make it available to other users within their 
disciplines. Unless otherwise negotiated as a part of 
the PIP, archiving of payload data will be handled by 
sponsor organizations - the S&T Centers or the DOCs. 

III.D.2. Platform User Flows 

The process by which a platform is developed, launched 
and operated is quite similar to that by which the core 
resources are distributed and utilized, although it is 
handled entirely separately. There are, however, some 
major differences. First, since the platforms will be 
sponsored, built and operated by the individual 
partners, most platform decisions will be taken by the 
sponsoring partner without requiring approval by the 
other partners. Only those activities which draw on 
common resources (e.g., servicing missions which 
utilize the manned base) will be subject to the review 
process outlined above. 

Second, most of the organizational entities involved in 
handling platform operations will be independent of 
those responsible for the manned base. A Platform 
Support Center (PSC) will correspond to the Space 
Station Support Center (SSSC), and will also handle 
the relevant responsibilities of the Payload Operations 
Integration Center; these latter responsibilities will be 
much less extensive than those necessary to operate 
the core Station. Within the Utilization and Opera- 
tions Development Division, the Utilization and 


Operations Integration Office, the User Accommoda- 
tions Integration Office, and other relevant offices, a 
separate subdivision will exist to handle platform- 
related activities. 

The following sections detail the process by which a 
new platform is developed, and the process by which 
new payloads are added to an existing platform. The 
text refers to Parts 2 and 3 of the detailed user scenario 
flowchart associated with this volume. 

Development of a New Platform 

(1) Selection of Platforms and Payloads 

In general, platforms will be discipline-oriented (i.e., 
developed to pursue a specific line of research). The 
sponsor (either a NASA office, another government 
agency such as NOAA, or a private sponsor) will 
develop a proposal for a platform, and discuss the 
requirements with the OSSO Utilization and Opera- 
tions Planning Office. The OSSO will act as an agent, 
procuring common hardware elements from the 
relevant contractors. This arrangement will reduce 
the cost of the platform hardware to the sponsor, and 
will ensure compatibility with Station operating and 
servicing procedures, standards and hardware. 

The sponsor must then obtain funding for both the 
platform hardware itself and for the individual 
payloads. The SSUB will review the platform proposal 
to ensure that it meets the goals of the U.S. user 
community. Once approved by the SSUB, the Office of 
Space Station Operations will assign a mission 
manager to oversee all activities relating to the 
platform. 71 The sponsor will release an Announcement 
of Opportunity (or otherwise solicit principal investi- 
gators), and select payloads for definition. 

The Utilization and Operations Planning Office will 
assist the sponsor in performing feasibility and 
compatibility reviews - ensuring that the payloads 
selected are compatible with the platform hardware 
and with each other. The relevant operations organiza- 
tions will support these assessments. These reviews 
will allow the sponsor to select the users whose experi- 
ments will make up the initial complement of platform 
payloads. 

Once the feasibility and compatibility assessments 
have been completed, the sponsor and the user must 
agree on the user's resource requirements, operating 
regime, date of launch, and priority. The Utilization 
and Operations Planning Office will assist in develop- 
ing and negotiating the Request for Flight that lays out 
the terms under which the user's payload will fly. The 
SSUB will then review and approve the selected 
payloads and forward the list to the User Operations 
Panel for inclusion in the Consolidated Utilization 
Plan. At the same time, the Associate Administrator 
for Space Station Operations must sign off on the 
agreements, indicating his office's commitment to 
building and operating the platform, and to the 
schedule laid out. 


n lf desired, the sponsor can provide the mission manager. 
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(2) Payload and Procedures Development 

Once approved by the sponsor and the Associate 
Administrator for Space Station, the user will begin to 
develop his payload and procedures. As discussed for 
the manned base users above, a Payload Accommoda- 
tion Manager will be assigned from the Office of Space 
Station Operations' User Accommodations Integration 
Office. The user will develop his payload and complete 
a series of operations and design reviews. (The 
operations reviews are performed by the Space Station 
Operations office with support from the sponsor; the 
design reviews are performed by the sponsor with 
support from the SSP operations office.) The Payload 
Accommodation Manager is responsible for ensuring 
that all reviews, assessments and planning involving 
that payload's interaction with the platform. The 
Mission Manager coordinates all payload activities, 
conducts Operations Readiness Reviews, and coor- 
dinates development of the Increment Operations Plan 
and supporting procedures and data with the support of 
the PSC execute planning team. The sponsor ensures 
that the payload meets its own goals and requirements. 

The Utilization and Operations Planning Office will 
negotiate a launch date and launch services agreement 
with the Office of Space Flight. 

(3) Delivery of Payload Emulators/Simulators 

Some months prior to launch (the exact time remains to 
be determined), the user will deliver payload emulators 
and simulators to the Integration, Test and Verifi- 
cation Facility (ITVF). The ITVF will integrate these 
hardware and software models for use in training the 
platform operations ground crew and for user training. 

(4) Delivery and Integration of Payloads with 
Platforms 

Some months before launch (time dependent upon 
payload complexity), the user will deliver the payload 
for integration into the platform. The platform may be 
integrated by the sponsor itself, or by the ITVF. The 
user will provide launch site support as necessary, 
monitored and assisted by the PAM. After integration, 
the Cargo Integration Group will perform final inter- 
face testing and loading, and prepare the platform for 
integration into the launch vehicle. The Office of Space 
Flight will then launch the platform. 

During this period of time, the user will undergo 
training in platform/payload operations. The ITVF 
will oversee this training activity. 

(5) On-Orbit Check-Out, Verification and Operations 

Once the launch vehicle has placed the platform in 
orbit, the Platform Transfer Operations Center within 
the Platform Support Center will perform any orbital 
adjustments, system check-out and verification, and 
other activities required to bring the platform into 
working order. Then the users will perform payload 
check-out and verification, with the PSC providing 
interface coordination and control. Once all payloads 
and systems are up and running, the users will partici- 
pate in replanning on an as-needed basis. The PSC will 
notify the users, via the Platform Investigators 


Working Group, of any changes in platform resources 
or capabilities. The Platform IWG will negotiate any 
disagreements, and develop a new user operations 
plan; the PSC will ensure that this plan is followed by 
the users. 

Addition of New Payloads to an Existing Platform 

The sponsors may plan to change out some or all of the 
payloads for new ones after the platform has operated 
for a time. The sponsor must obtain approval for a 
change-out mission involving either the Space Shuttle 
or the Space Station. 

(1) Development of a Change-Out Mission 

Having planned for some payloads to be changed out, 
the sponsor must solicit and select new users via the 
process outlined above. The Mission Manager must 
then oversee the development of a consolidated mission 
plan for payload change-out. Since this mission will 
involve the manned base and its crew, the safety 
reviews, training and other operations and planning 
elements for manned base operations must be involved 
in developing the mission plan. 


(2) Approval by the MCB 

Because the change-out mission will involve SSP 
resources that are under the purview of all the part- 
ners, the mission must be reviewed according to the 
multilateral process outlined for manned base users. 
Once the SSUB has approved the consolidated change- 
out mission, the proposal will be forwarded to the UOP 
for inclusion in the CUP and approval by the MCB. It 
will follow the same strategic and tactical planning 
process followed by all manned base users. 


(3) Payload and Procedure Development 

The development of the user's payload and procedures 
will occur in the same manner outlined in the New 
Platform scenario, except that he will have to be 
compatible with the platform operations environment 
and either the manned base or STS operations environ- 
ment. The user's PAM will be his agent for 
interactions with both organizations as required, and 
will ensure that differences in organizational protocol 
are as transparent to the user as possible. 

The Platform IWG will work with the PSC as described 
above to develop a platform operations plan. The 
PIWG will also work with the POIC and SSSC to 
develop plans for check-out and verification activities 
at the manned base before the platform is returned to 
its operational orbit. The Platform IWG will represent 
all platform change-out users on the Increment 
Working Group overseeing the manned base operations 
during the increment when the change-out will occur. 
This participation will ensure that platform require- 
ments for crew operations, checkout and verification 
and other manned base operations are met. 

The user will deliver hardware and software payload 
simulators to the Space Station Training Integration 
Group for use in crew training (for the physical change- 
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out of the payload), ground crew training (for operation 
of the platform), and user training. Training will occur 
as described above. 

The user will deliver his payload either to the sponsor 
via an S&T Center, where it will be integrated into 
special carriers or other equipment, or directly to the 
Cargo Integration Office for integration into the 
logistics module or other carrier. He will provide 
launch site support as necessary. 

(4) On-Orbit Operations 

At some point prior to the payload launch, the Platform 
Transfer Operations Center will maneuver the 
platform in for docking with the Station. When the 
platform is operated within the vicinity of the manned 
base (i.e., for servicing missions), the PSC will work 
under the direction of the SSSC to ensure the safety of 
the manned base and crew. 


Once the payloads and the platform are at the Station, 
the crew will perform the change-out. This may occur 
while the Shuttle is still docked with the Station so 
that the payloads being removed can be returned to 
earth with the Shuttle. The user will monitor this 
activity, if necessary, from his own facilities or from 
facilities at the S&T Center or elsewhere. If desired, 
the user can perform check-out and verification proce- 
dures to ensure that the payload is in operating order, 
prior to the platform’s release from the Station. The 
POIC and SSSC will provide interface coordination and 
control, as described in Section IE. 


Finally, the platform will be returned to its operational 
orbit; the Platform Transfer Operations Center in the 
PSC will work with the SSSC to perform these 
maneuvers and reestablish the platform in its specified 
orbit. Regular operations will then begin as described 
above. 
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IV. SPECIAL TOPICS 


The Task Force, in conducting its review of Space 
Station operations, recognized that there were a 
number of issues of importance which were not a direct 
focus of the Framework, but which would affect the 
ability of the operations organization to meet Program 
goals. This section provides brief summaries of these 
issues: 

a. Program Observations 

b. Program Operations Costs 

c. International Issues 

d. Proprietary User Operations 

e. Station/STS Operations Synergy 

f. Safety 

g. Station Pricing Policy 

h. Crew Training 

i. Space Station Information System (SSIS) 

j . Space Station Management Information System 

IV.A. PROGRAM OBSERVATIONS 

The SSOTF effort took the CETF baseline Space 
Station configuration largely as a "given”; however, as 
part of its charter the SSOTF was asked to evaluate the 
adequacy of that baseline to meet user and system 
requirements. In its analysis, the SSOTF identified 
several potential trouble spots in the baseline 
architecture. These deficiencies could reduce 
operational flexibility; hence, the Task Force includes 
the following Program observations and design 
considerations for further Program review. 

Other Space Launch Vehicles 

Current planning for Station operations assumes that 
there will be eight STS flights per year dedicated to 
Space Station support (manned base and platforms). 
The Phase B definition studies of Station up/down mass 
and crew transfer requirements indicated that this is a 
minimum requirement. Projected upweight transport 
requirements are beyond the capacity of the Shuttle 
bay, and suggest that expanded operations would not 
be possible unless a higher percentage of STS flights 
could be devoted to the Station, Shuttle upgrades were 
implemented which materially enhanced the carrying 
capacity of the fleet, additional orbiters are added to 
the fleet 1 , or use of ELVs is considered. 

The likelihood of devoting a higher percentage of 
existing capability to the Station was dismissed 
because of the continuing requirements to use the 
Shuttle for other high priority government missions. 


In fact, it appears likely that the Station will have 
fewer STS flights available. NASA’s joint Space 
Flight/Space Transportation Study, performed 
separately from the SSOTF effort, has examined 
whether it is possible to reduce the number of dedicated 
STS flights to five or less. 2 


The major vulnerability of lower STS support 
projections is in payload transfer, rather than crew 
transfer. (With five or more STS flights per year crew 
support capability is not affected.) For example, by 
extending crew stay times from 90 to 120 days and 
increment periods from 45 to 60 days, STS Space 
Station flights can be cut from eight per year to six. 3 
However, the cost, in terms of user operations, would be 
severe. Over 100,000 lbs. of transport capacity would 
be lost, and most of this would be absorbed by user 
payloads. (Supplies to support and maintain the crew 
and Station systems can be likened to fixed costs, and 
are relatively insensitive to STS flight rate.) 

The Task Force suggests that NASA utilize expendable 
launch vehicles to the fullest extent feasible for both 
the Development and Mature Operations Phases of the 
Program. Specifically, the SSOTF judged that ELVs 
could be used for launch of the polar orbiting platform, 
and for logistics supply to the Station. Addition of 
ELVs would allow the STS/Station interface to be 
maximized for crew-related transfer and the launch 
and return of high-value payloads. The Task Force did 
not recommend the use of a specific ELV; it was 
acknowledged that the Program should be able to draw 
on any available vehicle, including a "heavy lift” 
vehicle, as logistics and payload transport needs 
dictate. 

The Task Force also recognized partner interest in 
development of new manned space transportation 
vehicles. The Task Force believes that these vehicles 
could provide a valuable augmentation of Space 
Station logistics capability (especially for crew 
transfer), but noted that it should be incumbent upon 
the developers of new manned systems to make them 
compatible with the Space Station, rather than the 
reverse. 

Downweight Limitations 

The Space Station Program currently baselines the use 
of the STS for the return of all materials from the 
manned base to the Earth. With eight flights per year, 


Provision of additional orbiters, given existing budget constraints, was not pursued as an option available to the SSOTF. 

2 This analysis projects that even with a 10,000 lb capacity augmentation and the exclusion of the orbiter. Columbia from the Space 
Station support role (Columbia’s payload capacity is 7 £00 lbs. less than the newer orbiters), a minimum of six flights per year is required to 
meet payload mass transport requirements. 

3 NASA 's manned spaceflight experience base allows for crew staytimes of up to 135 days (projected from Sky lab experience by the life 
sciences experts). Assuming an eight man crew, and the ability to "change out" four crew members per mission, the minimum STS 
requirement is 5.4 flights per year. At lower flight rates, either entire crews must be changed out (which suggests a change to single shift 
crew operations with a maximum Station crew size determined by maximum STS passenger capacity), or partial crews must be changed 
out which counters the SSOTF recommendation that crew teams train and work as a unit. It is assumed that maximum staytime on orbit 
will increase as experience in long duration flight grows. A 180 -day stay time would allow crew team changeout with only four flights per 
year. 
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the STS appears incapable of accomplishing this task, 
even after subtracting the mass of consumables (such 
as air and water) which can be vented overboard. 4 

The SSOTF believes that it is inefficient for the STS to 
ferry back "garbage”’ from the Space Station. One 
potential solution for this problem is the development 
of lightweight, low-cost disposable canister or 
packaging system for deorbiting non-toxic materials 
from the Station. The canister would burn up upon 
controlled reentry; 5 the STS capability would then be 
reserved for the return of crew and high-value products 
and equipment. 

Emergency Crew Return 

One of the key design and operational issues for the 
Space Station Program is crew safety. The reference 
configuration provides a 28-day "safe haven" capability 
in the event of a major onboard failure (e.g., 
depressurization of the habitation module). This period 
was determined at a time when planners expected the 
four orbiter fleet would be capable of 24 flights per 
year. It was judged that four weeks would be sufficient 
time to "scramble” a rescue mission. 

The Challenger tragedy illustrates the risk in relying 
solely on the orbiter fleet for emergency return 
capability. A catastrophic accident may ground the 
fleet for years; less severe anomalies could result in 
downtimes of several months. Should the Space 
Station crew be reliant upon the STS for emergency 
return, NASA would face the decision to launch a 
rescue mission with a high risk of failure. 

The SSOTF’s analysis of on-orbit crew health also 
indicates the need for a more rapid return capability in 
the event of major illness or injury to one or more crew 
members. 6 Using the Soviet long-duration flight 
experience as a proxy, the Program can expect 
problems requiring rapid crew return to Earth to occur 
every 1-2 years (assuming an eight man crew). Even if 
a Shuttle flight could be launched within 28 days, it 
might not be soon enough to save the afflicted crew 
members. 

For both of these reasons, the Task Force recommends 
that NASA more fully incorporate emergency crew 
return concepts into current Phase C activities. (See 
Section V for complete recommendations.) The SSOTF 
did not conduct a full analysis of emergency return 
requirements; however, a few parameters were defined. 
First, the vehicle should not require extensive crew 
operation, as the Space Station crew members will not 
possess the same type of pilot’s skills as STS pilots and 
commanders have. Second, the vehicle should have a 
low-G re-entry profile (3G max.) consistent with 
transport of an injured or ill crew member. Finally, the 
emergency crew return capability should incorporate 
basic medical stabilization capabilities (intravenous, 
electrocardiographic). 


Onboard Environment 

The goal of environmental monitoring (EM) is to 
quantify and track all potential biological hazards. 
The EM system must be capable of measuring volatile 
substances (organic and inorganic), particulate matter, 
and the microbial load of the manned base atmosphere. 

The manned base EM requirements are significantly 
more extensive than those for the STS. Manned base 
mission duration precludes the assessment and 
certification of the internal environment by post 
mission analysis of samples obtained in flight. 
Experimental activities such as materials processing, 
combined with the inability to return the manned base 
to earth for complete cleaning between missions, and 
the effects of "tight building syndrome” require EM to 
be performed continuously on the manned base. 

Onboard contamination without sophisticated 
capabilities to rapidly monitor, identify, quantify, 
contain and control toxic substances could force 
immediate or eventual evacuation. The Space Station 
Program should immediately initiate and support a 
vigorous EM project which incorporates a materials 
safety identification and review process, an EM 
monitoring system, procedures design to prevent or 
minimize materials interaction problems, development 
of procedures and equipment necessary to contain a 
toxic hazard, and development of procedures, 
equipment, and non-toxic cleansers and disinfectants 
for routine maintenance and periodic cleaning of the 
manned base. 

Interoperability of Ground Systems 

The SSOTF notes the need to provide for interoper- 
ability of critical functions within the Program’s 
command and control ground facilities. The majority of 
the ground network support facilities are not currently 
planned to be redundant. For example, the SSSC 
might be capable of supporting platform operations if 
there is a major failure at the PSC or vice versa. The 
Task Force suggests that there should be no single 
point failure nodes allowed in the design of the 
command and control network for any of the space 
elements, and further notes that the proper time and 
place to build in interoperability is from the 
beginning, and through marginal upgrades of baseline 
ground support facilities. At a minimum, there should 
be a redundant capability for basic manned base 
system support: the PSC and POIC (separately, or in 
combination) must be capable of supporting manned 
base housekeeping requirements in the event that the 
SSSC is rendered inoperable. 

Loss of Critical Element 

The Program baseline includes only one copy of each 
major manned base hardware element. The Task Force 
notes that there is no recovery plan for loss of a critical 


4 While the STS can carry approximately 32,000 lbs. of payload on Station support flights, the orbiter 's payload landing capacity is only 
25,000 lbs. This figure is inclusive of the mass of the logistics module or any other flight support equipment. 

5 The Soviet Progress expendable launch vehicle already incorporates this capability. 

6 Such illnesses include relatively ''common*' problems such as appendicitis, gall stones, kidney stones and ulcers. Unfortunately , the 
empirical database for predicting medical risk is incomplete, and " close analogies " (e.g., experience on submarines) are not fully 
transferable to the Space Station. 
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element, nor is there yet detailed consideration of 
spares requirements or policy. Task Force Members 
knowledgeable about the STS spares program note that 
lack of a coherent policy for spares buildup and 
inventory has resulted in higher operations costs for 
the STS program, and that it should not be allowed to 
recur in the Space Station Program. The SSOTF 
suggests that spares and replacement policy and 
directives should become integral to Phase C design 
and later operations and considerations. 

Polar Platform Servicing 

The availability and capability of the STS to support 
polar orbit missions remains a source of concern. As 
noted above, the Office of Space Flight and Office of 
Space Station are examining ways in which the 
Program's dependence on the STS can be reduced to 4-5 
flights per year. The Task Force recommends launch of 
the polar platform using an ELV as a means of 
conserving valuable STS capability and enhancing 
platform performance. (See Section V.) 

Task Force members also remain concerned over the 
ability of the STS to perform polar orbit servicing 
missions. First, there is uncertainty as to the 
availability of the VAFB SLC-6 launch site. Secondly, 
the Task Force questioned whether the cost of polar 
orbit servicing missions, when combined with the 
lowered STS payload capacity, warranted development 
of a serviceable polar platform. The SSOTF suggests 
that the Program reconsider polar platform design, to 
see whether planned missions can be more efficiently 
conducted using "throwaway” platforms launched by 
ELVs. 


Commonality 

The Task Force noted that commonality in Station 
design and operations procedures among elements will 
significantly improve the safety of on-orbit operations, 
and can generate significant cost savings as well. At 
present, commonality in element hardware is not a 
requirement, and some would prefer that the partners 
retain freedom to develop their own components and 
sub-assemblies, consistent with agreed-upon reliability 
standards. 

SSOTF members noted that there were several means 
of ensuring that such commonality preserve the 
industrial perogatives of the partners. For example, 
common hardware components could be allocated on a 
partner basis in proportion to the partner’s total 
contribution to the Phase C effort. This implies that 
the U.S. modules would incorporate some foreign-built 
hardware, and that U.S. hardware would be 
incorporated into the foreign modules. Alternatively, 
common component designs could be licensed among 
contractors within each partner’s jurisdiction. This 
would have the additional benefit of ensuring multiple 
sources of supply, but may result in higher costs per 
unit. 


Space Network Support 

Although there have been past studies pertaining to 
the closing of the Zone of Exclusion (ZOE) wherein 
communications with the ground are lost, the SSOTF 
suggests that new trade-off studies should be done to 
determine the costs and benefits of providing 
continuous "acquisition of signal” (AOS) during 
manned base operations. This would prevent routine 
data loss or interruption due to such things as TDRS 
handovers and ground station ZOE periods. This 
suggestion is based on experience and lessons learned 
from Skylab, Spacelab, and STS payload missions 
where the crew members’ premium time was spent 
tending onboard tape recorders, and ground personnel 
time was spent developing recording timelines and 
supporting level-zero processing functions because of 
ZOE-induced onboard tape recorder playbacks. 

It is extremely important to provide the potential for 
continuous AOS in order to meet anticipated user 
requirements for the conduct of unencumbered 
telescience operations during the Mature Operations 
Phase. The trade studies should develop alternative 
approaches and assess the impact of Space Network 
assets. Alternatives should include the potential 
availability of International Space Networks and of 
U.S. commercially available capabilities. 

Logistics Planning 

The provision of logistics support and design 
acquisition engineering inputs to the operational Space 
Station represents one of the major cost drivers of the 
Program, and is the most sensitive to the adequacy of 
design considerations given during the Phase C/D 
activities. The logistics subpanel addressed the 
spectrum of logistics issues from design to mature 
operations and across all Program elements, including 
the institutional support elements necessary for the 
thirty-year life of the Program. 

The subpanel strongly supports the creation of an 
Integrated Logistics System which coordinates 
planning for system and user logistics, inventory, 
warehousing, and user payload verification and 
testing. 7 The Task Force was concerned with the lack 
of commonality in the ILS approach and specification 
in the Phase C RFPs for NASA elements. Hence, the 
SSOTF sees a need for the immediate establishment of 
a logistics planning function at the Program 
Integration Level in the transition organization to 
oversee the development of all logistics activities. 

Crew Health Maintenance 

The manned base in-flight health care delivery system 
must incorporate the triad of modern medicine: 
prevention, diagnosis, and therapy. These functions 
must be performed with the capabilities of the Health 
Maintenance Facility. Given the presence of basic 
preventative, diagnostic and therapeutic equipment, 


7 In fact , an integrated logistics system is a logical follow-on to the integrated operations and utilization concept of the Recommended 
Framework . 
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the effectiveness of the in flight medical system is 
greatly dependent on the level of onboard medical 
expertise. The advantages of a crew member who can 
perform "routine” medical diagnosis and treatment are 
obvious. For a crew size*of eight, at least two crew 
members should have a minimum of emergency 
medical technical training. 


IV.B. PROGRAM OPERATIONS COSTS 

In past space systems programs, the relative 
magnitude of development costs have overwhelmed 
operations costs in calculating total program costs. 
However, over the long lifespan foreseen for the Space 
Station, operations costs will play a much greater role 
in determining the Program's total life-cycle cost (LCC) 
(combined development and operations costs). Over the 
time horizon envisioned for Space Station, operations 
costs represent more than half of the LCC, even when 
those costs are discounted over time. 

Program Cost Impact 

The Task Force considered cost as one of several major 
factors in selecting operations concepts, but did not 
conduct a separate "bottom-up” cost assessment. The 
Task Force reviewed the recently submitted Space 
Station costs estimates for baseline Station operations 
and estimated the relative cost impact for each major 
new or enhanced facility or function required to 
support the Recommended Framework. In addition, 
the Task Force identified facilities and elements that 
were already identified in the baseline program, but 
which were inadvertently omitted from earlier 
development and operations cost exercises. 

New or Enhanced Capabilities 

• Payload Operations Integration Center: The 
Recommended Framework requires a Payload 
Operations Integration Center (POIC) to 
consolidate and manage user operations for the 
manned base. The POIC will require significant 
data management, communications and operations 
capability. The Task Force determined that the 
POIC should be located at Marshall Space Flight 
Center, separate from the SSSC. 

• Medium Fidelity Lab and Hab Simulators: The 
addition of the POIC and its user integration 
responsibilities along with the anticipated 
increment crew training loading will require 
additional training facilities. These will include an 
additional medium fidelity habitation module and 
node simulator at MSFC and an additional medium 
fidelity U.S. lab module simulator at JSC. As well, 
both MSFC and JSC will require partner-funded 
medium fidelity ESA and NASDA lab module 
simulators. 

• Payload Engineering Support: The Task Force 
concluded that user/payload integration engineer- 
ing requirements have been underestimated; the 
scope of responsibilities identified by the SSOTF 
will significantly increase currently estimated 


manpower requirements. This additional support 
was assumed by the Task Force to be supplied using 
existing Center facilities. 

• Master Integration Facility at Launch Site: The 
Task Force recognized that the international 
partners will require facilities at the launch site to 
carry out pre-launch and post-launch processing of 
logistics carriers for their elements. This Master 
Integration Facility will require modifications to 
the Space Station Processing Facility. 

• Increment Change Management: The SSOTF 
concluded that increment management responsi- 
bilities were relatively undefined and substantially 
underscoped, and concluded that a separate incre- 
ment change management office would be required. 

• Upgrade of Baseline Communications and Tracking 
Capability: The Task Force concluded that Station 
operations would require increased capacity in the 
communications and tracking system (particularly 
the TDRSS or its replacement), including the devel- 
opment of S-band data communications capabilities 
and expansion of planned Ku-band capability. 

• Logistics Module Design Modification: The Task 
Force determined that the logistics module design 
should be modified and access to the Shuttle launch 
facilities should be reviewed with the Office of 
Space Flight to permit late/early access to per- 
ishable supplies or experiments, or to tend living 
specimens while on the launch pad consistent with 
STS safety policy. 

• Hardware and Systems Commonality with Interna- 
tionals: The Task Force suggests that the U.S. and 
the International partners design hardware and 
software systems to permit the greatest possible 
commonality in order to increase efficiency and 
safety in onboard operations. 

• Environmental Monitoring System: The Task Force 
suggests the addition of an environmental monitor- 
ing system to support safe crew operations. 

• Additional Payload Racks: Additional payload 
racks will be required to permit rack/payload 
integration to be distributed to user-sponsor 
facilities to support decentralized payload/rack 
integration. 

Facilities/Capabilities Underscoped in Baseline 
Requirements 

The following resources will be required regardless of 
the operations framework selected; they were 
identified by the Task Force as missing from previous 
studies. 

• New Logistics Information System: The existing 
KSC Inventory Management System (KIMS) will 
not be capable of supporting the volume of 
information involved in Station operations. Thus 
the Program must augment KIMS for the inventory 
management function and develop a new Logistics 
Information System (LIS). The LIS should be 
broader in scope than KIMS, encompassing 


92 



maintenance and repair management, storage and 
retrieval of logistics support analysis data, and 
resupply/repair management. 

• New Logistics Warehouse: Station supplies and 
logistics carriers in combination with the depot 
maintenance and repair function will generate a 
sufficient volume of materials and operations that 
they will require a new logistics warehouse to house 
them. 

• Underscope of Logistics Support Requirements: In 
addition to identifying the above facilities 
requirements, the Task Force concluded that the 
scope of maintenance and repair requirements has 
been underscoped, and will require significantly 
greater manpower than previously estimated. 

• Station/Platform Compatibility with ELVs: The 
Task Force reemphasizes the CETF recommenda- 
tion that Station elements and platforms be 
compatible with ELVs to permit flexibility and 
robustness in launch capability. 

• Hooks and Scars for Evolution: The Task Force 
reemphasizes past recommendations for hooks and 
scars to permit evolutionary upgrades to Station 
systems to support increased autonomy and 
operations efficiency. 


Operations Cost Management Process 

In examining the issue of Space Station Program costs, 
the Task Force concluded that these costs can be 
managed effectively only if they can be confidently 
estimated. While the effort required to build the 
methods and models for such estimates may be high the 
potential payoff to the SSP is significantly higher. 
Thus, the Task Force concluded that the Space Station 
Program should adopt an annual operations cost 
estimating process which accounts for all major 
activities required for Space Station operations. This 
process should support: 

• Life-cycle cost estimating and related incentives 
evaluations essential to the Phase C/D engineering 
design-to-cost efforts; 

• Overall performance/cost tradeoff assessment 
studies needed to provide guidance in system 
evolution and operations procedures development; 

• Performing operations risk assessments as they 
relate to life cycle costs; 

• Evaluating contractor estimates; 

• International cost sharing formulation and 
exchange rate/media determination; 

• Program and related pricing strategies; 

• Performance of operations cost risk assessments; 

• Evaluation of contractor estimates; 

• Annual budget preparation 


The process should be formalized and cover all 
significant aspects of the Program. To facilitate such a 
process the Program should establish a logical 
consistency between the Program Work Breakdown 
Structure (WBS) and the Unique Project Number 
(UPN). The process should be tightly integrated with 
the Program’s Operations Performance Assessment 
efforts. 

Purpose of an Operations Cost Model 

As a first effort, the Program should consider 
formalizing development of an operations cost model as 
a major component of its operations cost management 
efforts. An operations costs model will serve several 
purposes during both the Development and Mature 
Operations phases of the Space Station Program. First 
and foremost, the model can provide a systematic 
method for assessing trade-offs between program 
design and operations decisions on the one hand, and 
the operations cost portion of LCC on the other. 

The development of an integrated cost model provides 
an important alternative to conducting a series of grass 
roots cost exercises in response to "what if’ questions. 
The consistency in assumptions and methodology 
enforced through the use of a model allows more 
reliable analysis of the results, since it eliminates any 
variances caused by individual perspectives or biases. 
A well-constructed cost model guarantees reproduci- 
bility of results, ensuring that any differences in cost 
projections result from different assumptions, not from 
the biases of the user. 

Grass roots operations cost exercises do have value. 
However, they may provide a way of validating an 
operations cost model (or its parameters), and they may 
provide the operations cost modeler with special 
insights into the true sources of costs since the data is 
usually generated by personnel actually performing 
the operations tasks and is often empirical rather than 
theoretical in nature. 

Characteristics of a Useful Model 

There are a number of very desirable characteristics 
that determine the long-term utility of any quantita- 
tive models. These include: (1) Responsiveness, the 
power to accommodate assessment of differing options; 
(2) Multiple Use Capability, the ability to address a 
number of operations costs issues and support a variety 
of applications; (3) Transparency, the supporting data 
and algorithms of the model should be easily accessible 
to the user; (4) User Friendliness, the ease with which 
the model can be manipulated by users with a 
minimum of training; and (5) Ease of Model Upgrades, 
the ease with which the model can incorporate data and 
algorithm updates as new experience develops new 
data and evolutionary trends change the basic 
assumptions of the model. 

Recommended Operations Cost Model 

To save upfront model development costs, the Task 
Force reviewed a number of existing cost models for 
applicability to Space Station Program operating costs. 
Based on its review of the available models, the Task 
Force concluded that the JPL MESSOC (Model for 
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Estimating Space Station Operations Costs) model 
should be adopted as a high-level Space Station 
operations cost model. MESSOC is an "activity- 
driven” model which asks the user what activities are 
programmed for each year. Activities may be classed 
as mission/payloads, transportation, and ground 
support. MESSOC then calculates what those 
activities cost, and what resources remain for 
additional activities. 

Once development is completed MESSOC appears most 
likely to meet the full range of requirements set out in 
this chapter. This recommendation, however, should 
not preclude the use of other contractor-developed 
operations cost models and programs for specific 
studies. 

Partner Cost Sharing Issues 

A final issue with regard to operations costs is the basis 
on which these costs are distributed among the 
international partners. There are a number of ways to 
share these costs, including: (1) pooling all functions 
and basing each Partner’s responsibility for the cost on 
its share of the utilization resources: (2) distributing 
responsibility to the partners both for individual 
functions and for their associated costs: (3) assigning 
each partner responsibility for the cost of functions 
associated with specific pieces of hardware; and (4) 
combinations of the above options. Any of these 
approaches might be negotiated among the partners, 
but each would have different implications for cost and 
management efficiency. 

As a general principle, it is desirable that each partner 
benefits from the partnership in proportion to what it 
contributes to it. Inversely, each partner wishes to 
avoid sharing in any operations cost inefficiencies 
introduced by any of the other partners. Furthermore, 
the cost distribution and management structure should 
minimize, or at least avoid increasing, the total cost of 
operating the Station. 

The actual method for distributing operations costs 
will be determined at the negotiating table. However, 
the Task Force made several observations as to the 
impact of these options on Station operations. First, as 
a general rule, it is desirable to have the partner who 
designs and builds a piece of equipment be responsible 
for the costs specific to that equipment as well. This 
arrangement establishes a strong incentive to develop 
hardware systems which are life-cycle cost effective. 
The U.S., which will provide a majority of the 
operating funds, has a very important stake in 
establishing the proper operating cost incentives. 

A second issue in international cost sharing relates to 
the potential for U.S. subsidization of international 
operations resulting from the integrated operations 
concept. Because of the increased interconnectivity 
between operations by the individual partners, it may 
be more difficult to separate out the costs incurred by 
each partner’s activities. As a result, it may not be 
possible to allocate accurately the overhead costs based 
on usage, and the U.S. may take up more than its share 
of these costs. However, this effective subsidization 
may be accepted as the price of reducing the overall 
costs of operating the Station and enhancing the safety 


of Station and crew. The effect may be minimized by 
improving systems for tracking actual use and 
estimating each partner’s share. 

IV.C. INTERNATIONAL ISSUES 

The SSOTF assumed that the foreign partners will 
participate extensively in all aspects of the Space 
Station Program, and endeavored to recognize the 
partners’ requirements and desires wherever possible. 
The Task Force believes that the recommended 
framework of Integrated Operations will support inter- 
national cooperation and provide for all envisioned 
partner activities in the Program. However, the Task 
Force recognizes that the partners would prefer to 
retain more responsibility for operations of the 
hardware elements which they contribute to the 
manned base. (Separate control of unmanned platforms 
is already a feature of the recommended framework.) 

In addition to the recommended Integrated Operations 
framework, the Task Force evaluated a Partner 
Element Operations framework as an option. This 
section provides a brief description of this option, and 
compares it with the recommended framework. 

In the partner Element Operations approach, each of 
the participating partners maintains and operates its 
respective flight elements on the manned base (similar 
to the platforms operations approach). NASA would 
retain overall management responsibility for planning 
and managing the manned base, but Program 
Integration and Program Execution Level functions 
would be carried out on a partner/element basis. 

Top level policies for resource allocation and systems 
evolution would be accomplished through international 
negotiation (as in the recommended framework). 
Resources would be allocated to elements and then to 
user categories (demographic or disciplinary). 
Manifesting would be performed separately for each 
element, presumably at geographically dispersed sites 
and then coordinated among elements. Payload 
integration would be performed by the participants at 
their respective integration facilities. 

NASA would retain responsibility for space transpor- 
tation manifesting. Operational integration of systems 
and payload activities would perform duties in their 
respective elements. Operations support for both 
Station systems and users would be conducted at 
separate element support facilities, although the 
NASA SSSC would retain overall responsibility for 
manned base integrity and crew safety. Systems 
evolution would be performed at each element’s ESC 
(as in the recommended framework), but configuration 
control and SE&I functions would be the responsibility 
of the element systems support center. 

A comparison of the Partner Element Operations 
option, with the Integrated Operations option 
contained in the recommended framework, is presented 
in Table IV- 1, and summarized below. 

Program Control 

The SSOTF concluded that an operations framework 
based on Partner Element Operations could be 
managed, but that it would present a substantially 
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OPTIONS 

PARTNER ELEMENT 

INTEGRATED 

CRITERIA ^ 

OPERATIONS 

OPERATIONS 

PROGRAM CONTROL 

Q 

• 

PROGRAM SAFETY AND SYSTEM 
INTEGRITY 

Q 

• 

EFFECTIVE USER OPERATIONS 

W 

• 

SUBSTANTIVE INTERNATIONAL 
PARTICIPATION 

• 

Q 

ASSEMBLY AND EVOLUTION 

w 

Q 

OPERATIONS COST EFFECTIVENESS 

w 

• 




RELATIVE RANK 

2 

1 

ADVANTAGEOUS- 

ACCEPTABLE- 

UNACCEPTABLE- 


Table IV-1 Operations Control Options Assessment 


greater challenge than Integrated Operations. In the 
context of normal operations, the separation of 
utilization and operations planning necessitates extra 
steps in developing both Tactical Operations Plans and 
Flight Increment Plans. Coordination of system 
support and user operations support is also a much 
more difficult management task, as the activities 
which could, or which might , affect more than one 
element would have to be coordinated through multiple 
system support centers. A distributed authority 
system would also inhibit the flow of "lessons-learned” 
across elements in the Program. 

The system’s ability to handle off-nominal events 
would pose a more significant challenge. A major 
system failure in one element, or failure of a 
distributed system, will require a concerted response; 
separation of decision making authority would require 
elaborate contingency plans worked out in extreme 
detail . 8 Such a contingency would also require 
procedures for quickly determining the severity of an 
event. (At what point does an anomaly justify 
integrated action or assumption of NASA control of 
partner elements?) 

The integrated operations framework relies on a 
strongly centralized planning approach to permit 
maximum coordination of broadly distributed 


activities. Thus, planning activities at each level 
(strategic, tactical and execute) are carried out under 
the influence of one central organization, led by NASA 
but staffed by all partners. At the policy level, 
selection of users and onboard activities is handled in a 
distributed manner, allowing user disciplines to set 
priorities and select users independently, but 
manifesting is performed centrally. Similarly, at the 
Program Integration and Program Execution levels, 
each user activity is planned independently, but all are 
coordinated through a central planning body. 


The integrated planning effort ensures the most 
efficient distribution and utilization of scarce onboard 
resources, and allows a quicker response for replanning 
due to unforeseen opportunities. It also encourages the 
development of consistent end-to-end user accommo- 
dation and crew procedures (since all partners are 
working to the same schedules and parameters). Inte- 
grated planning would cut down on duplication of 
effort, and ensure cost-effective use of planning staff. 
Finally, a unified approach will allow for an effective 
conflict resolution process. The Task Force concluded 
that these advantages outweighed the disadvantages of 
the centralized planning approach (i.e., complex 
formulae/groundrules for provision of operations 
services and diminished autonomy of the partners). 


8 This would require major management investments , and would still leave the possibility that unforeseen anomalies would leave the 
partners debating over appropriate delegation of authority rather than focusing on the problem at hand. 
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Program Safety and System Integrity 

The SSOTF concluded that there is no prima facie 
reason why a framework based on Partner Element 
Operations could not be conducted in a safe manner, 
but the collective intuition and experience of the Task 
Force found little incentive for this approach from the 
safety and program integrity perspective. 

The basic concern is that a Partner Element Opera- 
tions framework requires additional management and 
operations interfaces (both personnel and equipment), 
and therefore increases the opportunity for miscom- 
munication or outright command/control breakdown. 
The separation of operations also suggests that over 
time, each element would develop its own operating 
procedures and standards. Configuration management 
is greatly complicated when sustaining engineering 
functions are not only geographically distributed but 
organizationally separated as well. 

Additionally, it was recognized that many operations 
may extend beyond the boundaries of one element. 
(For example, the MSC could be used to mount a 
payload on the JEM’s exposed facility.) Separation of 
operations authority and experience suggests that the 
ability of the two elements to "act in harmony” may be 
compromised. 

The SSOTF strongly felt that hazardous operations 
activities had to be centralized (for example, materials 
science work with toxic substances). The lack of a 
single system-level control for ongoing element 
operations would be analogous to having two air traffic 
controllers monitoring flights in the same geographic 
locale, but having separate supervisors. Given the 
potential cost of mistakes, the risk was not considered 
warranted. 

The lack of commonality in procedures development, 
crew training (and related control mechanisms), and 
the likely differences in operations among system 
hardware and software elements, introduces the 
possibility of inadvertent mistakes by the crew, 
especially in off-nominal situations. A major 
advantage of the integrated crew approach of the 
Recommended Framework was that it would provide 
all crew members with a standardized approach to the 
understanding of Station systems and performance 
characteristics, and as important, would promote a 
team approach to operations. (This affects not only 
safety, but user operations as well.) 


Effective User Operations 

The impact on user operations will be severe if a 
Partner Element Operations approach is selected. As 
noted above, the separation of utilization, planning and 
operations by element greatly increases the 
coordination requirements among elements: separate 
manifests must be drafted for each element, revised to 
be consistent within the element, then be adjusted to be 


consistent with overall manned base activities, etc. 
This will greatly inhibit the flexibility of users to make 
adjustments to their experiments, or for "quick is 
beautiful” payloads to be manifested. 

Resource allocation would still be determined by 
international negotiation, similar to the recommended 
framework. However, resources would be distributed 
in "blocks” to the element operators, who would 
perform manifesting for each element separately. Each 
partner would develop element CUPs, TOPs and 
increment plans which would require a compatibility 
check and resolution of incompatible manifesting. 9 
Such a system could adversely impact the activities of 
U.S. users who are manifested in partner modules and 
must work with the foreign procedures. Significantly, 
as much as 50% of the available resources in the 
partner elements could be allocated to U.S. users. 
Separation of manifesting suggests that users may 
have to learn the intricacies of three separate 
manifesting procedures. 

The SSOTF also judged that Partner Element 
Operations would eventually result in a lack of 
commonality in element flight support equipment. 
This issue is particularly important in user interfaces: 
rack and interface commonality will be an absolute 
requirement in order to permit distributed payload/ 
rack integration operations. Furthermore, non- 
standard interfaces would force users to understand 
and meet several sets of requirements if they wished to 
utilize the capabilities of different Station elements. 

Partner Element Operations would also severely 
inhibit the Station’s productivity to users on-orbit. A 
crew member dedicated to one module or specific set of 
payloads could suboptimize Station capabilities. For 
example, if one crew member is sick, crew dedicated to 
other elements may not have sufficient expertise to "fill 
in” and oversee some of the payloads and experiments 
for which the sick crew member was responsible. 

Substantive International Participation 

The one area where the Partner Element Operations 
option was considered advantageous by the SSOTF was 
in the area of international participation from the 
perspective of the international partners. It assigns a 
much higher level of responsibility to the partners for 
operations planning, management and execution, and 
therefore more completely addresses their desires to 
quickly develop a comprehensive experience base in 
space operations. 

While the Partner Element Operations concept would 
provide international partners with greater operations 
experience and responsibility overall, it might actually 
compromise some aspects of this objective. Partner 
Element Operations would complicate crew 
manifesting from the standpoint of providing 
recommended systems operations crew capabilities. 
Columbus and JEM astronauts would be required to 
perform both element systems and user support 


9 For example , three different SSUBs could develop increment plans which might place users with heavy power requirements all at the 
same points on the systems timeline , thus saturating the resource availability. Alternatively , one SSUB could assign a sensitive pointing 
experiment at the same time as another SSUB manifested a series of vestibular motion experiments. 
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activities; hence it is unlikely that they would be 
trained to provide any specialized systems support 
capabilities such as in flight medical responsibility, the 
ability to operate the MSC, FTS, or any crew return 
systems. While the majority of these activities will fall 
to U.S. astronauts, the Partner Element Operations 
option suboptimizes both U.S. and partner crew 
operations for the following reasons: (1) a higher 
percentage of U.S. crew requirements will be dedicated 
to systems support (and correspondingly less would be 
available for user operations support); and (2) there 
would be no opportunity for foreign crew members to 
develop flight experience in such tasks. 


Assembly & Evolution 

Partner Element Operations and Integrated 
Operations are both acceptable options with regard to 
supporting evolution, although the Task Force felt that 
Integrated Operations would be more effective. In both 
cases, planned changes in systems configuration or 
user activity would require the approval of the 
partners, and systems upgrade DDT&E would most 
likely occur at the ESC where the element was built. 

However, Partner Element Operations would 
adversely affect the ability to evolve for two reasons. 
First, it is likely that each partner would be proposing 
element upgrades which optimized performance of 
their respective elements; this might not always 
optimize the total system. (For example, separate 
power upgrades for each module may be less efficient 
than a block upgrade of the entire system.) Second, 
integration of proposed system upgrades would require 
coordination with the separate user, logistics and 
maintenance manifests of the element partners. 
Disintegration of unified standards and commonality 
would be more likely to occur, thereby raising not only 
a safety risk, but also making continued evolution 
increasingly difficult to plan and implement. 


Operations Cost Effectiveness 

Both Integrated operations and Partner Element 
Operations should allow effective cost management. 
However, as the number of interfaces rises, the costs of 
coordination rise, and the likelihood of duplicated o^ 
unnecessary effort is also magnified. Extra layers of 
management for utilization and operations planning, 
separate facilities for system and user operations 
support and their geographic separation, all introduce 
new elements of cost. A related aspect is that Partner 
Element Operations would severely hinder the 
productivity of the crew (the scarcest and most costly 
Station resource) in terms of the amount of activity 
which it could perform in both routine and off-nominal 
situations. 

In the final analysis, "acceptable” cost level is a policy 
determination, and Program partners could decide that 
the extra expense for Partner Element Operations is 
justified by its value to NASA’s partners. The SSOTF, 
however, believes that for any operations budget, the 
ability to increase the safety of the system or its utility 
to users is a greater virtue, and hence should be 
promoted. 


Summary 

Although the SSOTF did not recommend the Partner 
Element Operations option, it was recognized that a 
"workable” framework could be devised if political 
imperatives dictated such an approach. The Task 
Force judgment was that a framework based on 
Partner Element Operations would result in a 
significant sacrifice in the quality and efficiency of user 
support, as well as an increase in safety risk associated 
with hazardous operations. User support is a variable 
determined by Program management, and safety 
concerns can be met through acceptance and 
implementation by all the partners of suitable U.S. 
safety requirements. These are the key issues for reso- 
lution by the international negotiations. Depending on 
the negotiated position, the recommended framework 
of Integrated Operations could be significantly altered. 
Overall, Partner Element Operations is achievable at a 
cost in operational efficiency, but the majority of the 
SSOTF recommended framework could still be 
implemented and support this option. 


IV.D. PROPRIETARY USER OPERATIONS 

Users from several demographic and discipline 
categories will require the ability to perform 
proprietary operations onboard the Station complex. 
Commercial users will require the ability to protect 
proprietary research and development efforts, as well 
as more extensive pilot production efforts. U.S. and 
international users will need to protect any activities 
that are covered by technology transfer laws. 
Additionally, the Department of Defense will require 
proprietary protection for sensitive research activities. 
The SSOTF accommodated these requirements 
wherever possible in the development of its operations 
procedures. 


The requirement for proprietary user operations affects 
ground and onboard crew activities, data transmission, 
and pre and post-launch handling of the payload and its 
products. The major requirements of proprietary users, 
and the means forseen for handling them, include the 
following: 


Secured Data Transmission Capabilities 

Since a large proportion of user activities will be 
handled via specialized User Operations Facilities 
(UOFs) on the ground, data regarding a payload’s 
status and operations will be transmitted via the Space 
Station Information System. Furthermore, the 
payload owner will require interaction with the Station 
crew to monitor and direct the onboard activities. Both 
of these streams must be secured to avoid disclosing 
information concerning experiment hardware, goals 
and operating procedures, and results. 


The SSOTF concurred with previous user studies which 
recommended that NASA provide an encrypted uplink 
to the Station, and that users will be responsible for 
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protecting the data downlink as they see fit. NASA 
will also provide a privacy protected voice channel 
capability. 

Physical Isolation of Experiment and Crew 
Onboard 

Proprietary operations will require that the 
experiment be shielded or isolated onboard the Station 
to avoid observation by crew members not directly 
involved in the effort. The SSOTF concluded that this 
requirement could be satisfied by the use of physical 
barriers (such as curtains or movable partitions), and 
would be considered in the manifesting and placement 
of payloads in the Station modules. 

The SSOTF also recognized that a privately sponsored 
module may provide proprietary facilities on the 
Station, and the operations framework does accommo- 
date the training and operational requirements of 
making such a module effective. A private module 
operator may also provide a corps of bonded astronauts 
for use in proprietary operations. 

Private or Bonded Astronauts 

Some user operations may require the use of privately 
sponsored astronauts (Payload Scientists), or access to 
a bonded astronaut corps. The SSOTF framework 
provides for selection, training and operations with 
private Payload Scientists. Furthermore, existing 
NASA crew and operations policies will support the 
need for confidentiality in crew operations. 

Secured Pre and Post- Flight Facilities 

Proprietary users will require access to secure facilities 
during payload and logistics module integration, 
launch, landing, and deintegration processes. The 
SSOTF framework allows users to integrate payloads 
into racks at off-site facilities, permitting the user to 
protect the payload as he sees fit. Once at the launch 
site before or after launch, the Logistics Operations 
and Pre/Post Flight Operations Offices will accommo- 
date proprietary operations, or will interact with 
privately-provided services. Existing Shuttle policies 
will continue to protect proprietary interests during 
launch and return to earth. 

DOD Requirements 

The operational requirements of the U.S. Department 
of Defense were considered within the context of 
proprietary operations. DoD was considered by the 
SSOTF as a strongly proprietary user, but other 
driving operational requirements were not addressed. 
This approach allowed the SSOTF framework to 
accommodate the research and development activities 
identified by DoD as its primary goal for Space Station. 

IV.E. STATION/STS OPERATIONS SYNERGY 

The STS is currently the only transportation system 
baselined to support the Program, and will 


undoubtedly remain the primary system for transfer of 
men and material to and from the on-orbit elements. 
Since many of the operations functions performed for 
the Station must also be performed for the STS, there 
exist numerous areas of synergy where collaboration 
can improve overall efficiency. These opportunities 
exist in both the Development and Mature Operations 
Phases of the SSP. 


The SSOTF effort has been paralleled by the Space 
Operations Task Force (SOTF) under the leadership of 
NASA Associate Administrator Robert Aller. This 
effort has examined ways in which NASA can 
streamline its institutional structure to delineate R&D 
activities from operations, and to evaluate how to 
integrate management and operations of its current 
and future operations programs. (These include the 
STS, TDRSS and Space Station programs.) 

Cognizant of the SOTF activity, the SSOTF did not 
undertake a similar assessment. Instead, in 
developing the Recommended Framework, the Task 
Force members noted those areas where Station and 
STS operations organizations develop common policies, 
procedures, and specifications, wherever such 
standardization would enhance utilization and 
operations capability or reduce operations costs for a 
given level of activity. 


Two Caveats 

Although the SSOTF supports the idea of maximizing 
synergistic operations between the STS and Space 
Station, it also cautions that the Space Station 
Framework will be more able than the current STS 
operations of incorporating new advances in 
automation and management systems. Consolidation 
could result in counterproductive "torquing” of Station 
operations if "non-standard” STS procedures and 
formats are used as the baseline. A second issue noted 
by the Task Force is the potential to use the operations 
funding of one program to help correct present or future 
problems in the other. In short, the Task Force 
suggests that any efforts to implement synergy be 
baselined on the most efficient approach, and such 
relationships should attempt to isolate or "fence-off” 
funding devoted to the respective programs. 


Development Phase Opportunities 

During the Development Phase, the majority of Station 
assembly and verification operations will be performed 
by the STS organization, with crew remaining onboard 
the shuttle prior to the initiation of a permanently 
manned capability for the Station . 10 

Coordination between the STS and Station operations 
organizations can begin during the Station’s 
Development Phase for systems ”proof of concept” 
testing and crew development. Utilization of the STS 


w The SSOTF assumed that prior to permanent manning, the STS crew would perform all external assembly tasks, while Station crew 
would perform the internal outfitting and verification of the manned base modules and common systems. 
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as a Station operations testbed would allow high 
fidelity simulation of Station support facilities and 
procedures prior to deployment. Specific examples of 
prospective systems tests include: POIC/SSSC/MCC 
interface verification; verification of data/command 
links and interfaces from distributed user facilities 
(DOCs, ROCs, etc.) and verification of telescience 
communications with Station elements; and Station 
assembly techniques. 

STS flights also offer the opportunity to acclimate 
career astronaut Station crew members (Station 
Scientists and Operators) to on-orbit operations and 
training in IVA and EVA systems maintenance or 
payload operations techniques before beginning long- 
term Space Station flights. 

Mature Operations Opportunities 

Station and STS operations activities will generate 
parallel functional requirements, and on any given day 
the planning and operations execution for one program 
will have an analog in the other. The major conceptual 
difference is that the Station activities will be weighted 
more towards multi-user payload operations, while the 
STS activities will be weighted more towards flight 
systems operations. Additionally, it is important to 
note that integration activities for the Space Station 
must be done on-orbit, while STS integration is 
performed on the ground. 

Strategic Utilization and Operations Planning 

The Station and STS programs will have interfaces at 
all levels of utilization and operations planning. The 
development of the CUP must include assessments of 
transportation systems availability and capability, and 
transportation systems maintenance requirements. 
Strategic planning for Station systems growth and STS 
evolution should be coordinated. (I.e., the SSP should 
be a supplier of inputs to STS evolution planning, and 
SSP planning should take advantage of planned STS 
incremental or block upgrades.) 

The interfaces for this activity will be at the Program 
Policy level for the SSP, and the Shuttle Operations 
(processing and flight operations) and Shuttle Orbiter 
(logistics) organizations for the STS. These organiza- 
tions will also work together to coordinate ELV/OMV 
utilization and operations requirements at the CUP 
level. 

Tactical and Increment Operations Planning 

At the Program Integration level, the necessary level 
of coordination must become much closer. TOP 
manifests must "align” Station increments with STS 
flight schedules and capabilities. For each increment 


identified in the TOP, the Station and STS 
organizations must develop and approve the detailed 
"up” and "down” manifests and transfer operations 
schedules. Engineering analyses required to verify 
payload-to-Station interfaces and those to support 
Shuttle integration will share many common data, tool 
and personnel requirements. 

Logistics carriers integrated by the SSPF must be 
integrated into the STS by the launch site Shuttle 
payload processing organization. Late access payloads 
on the launch pad will require both STS and SSP 
launch site planning. Station planning for "payloads of 
opportunity” requires close monitoring of available 
space on STS Station support flights . 11 

Crew training facilities planning and crew training 
plans will have a high degree of synergy, and planning 
efforts for each will require coordination. (E.g., 
installation of a new capability for Station astronauts 
must not upset STS astronaut schedules, and vice 
versa.) 

STS rendezvous, berthing and transfer of payloads into 
the Station will necessitate highly integrated 
procedures and planning for each end of this activity. 
Station payloads scheduled for return must be removed 
from the Station and reintegrated into the STS. 
Payloads returned from orbit must be deintegrated at 
the STS landing site and handed back to SSP 
representatives or users. 

Areas where there will be obvious overlap (and hence 
opportunity for collaboration) include development of 
common procedures and standards for: safety 
assessments, hazard control, trajectory planning, 
rendezvous and berthing operations requirements (STS 
and OMV), and configuration control . 12 User 
accommodation requirements documentation (e.g., 
PIPs and Annexes) and support procedures should 
conform so that the STS operations organization is 
transparent to Station users. 

Operations Execution 

At the Operations Execution level, synergies exist in 
two forms: the potential for collaborative performance 
of operations functions, and the potential to co-locate 
functionally and operationally related facilities. The 
former offers the potential to decrease the number of 
personnel required to perform operations functions; the 
latter offers the opportunity to improve the efficiency 
by enhancing the capability to coordinate operations in 
real-time 13 and to realize some potential savings in 
facilities and support costs. 

A number of execution-level operations facilities have 
been identified which could be consolidated within a 


ll Station planners may also wish to use available space to launch material to the Station before it is needed , so that later flights can 
optimize unique or large payloads. 

12 Development of a common electronic database format , consistent with the TMIS, would allow this system to serve both Station and 
STS requirements. 

13 Empirical evidence from NASA 's previous programs shows that replanning and contingency operations have been much more efficient 
when the operations organizations have been able to meet "face -to -face. " 
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common structure, or from which the Station Program 
could take advantage of current STS capabilities and 
"corporate knowledge” to conduct Station operations. 

Logistics and Ground Operations Support 

The process of preparing payloads for transport to the 
Space Station is one in which users hand off payloads to 
the SSPF, which in turn hands them to the STS 
payload integration organization, which then hands 
the payloads back to the Station crew for on-orbit 
integration. The engineering analyses which support 
this activity can be performed in an integrated fashion, 
and the "up-front” specifications for users can combine 
the limiting factors of each stage in the ground-to- 
Station transfer process. 

Activities which can be developed in common format 
include test and checkout procedures, safety 
requirements and specifications, special handling 
procedures, and pad access procedures. The facilities 
used to train ground personnel in these activities can 
also be shared. Other opportunities include operation 
of an integrated LOC using a computerized database 
management system to store and track ORUs, STS 
spares and replacement items, and stowage maps. 
Another possibility is the training of a unified team for 
late access to the pad. (I.e., other missions may also 
require late access, and these could be supported by the 
same team trained in Station carriers.) 


Space Operations 

In the Mature Operations Phase, the STS will directly 
support the Station during transfer operations. 
Transfer operations include rendezvous/approach, 
remote manipulator system/mobile servicing center 
operations (including payload transfer and 
berthing/docking of the Shuttle Orbiter), STS "down- 
load” management (Station products and waste to be 
returned), and OMV operations (including 
retrieval/placement of the COP or other spacecraft and 
in-situ satellite servicing). In addition, STS/Station 
systems management of such items as fuel cell water 
transfer and control systems will be closely 
coordinated, as well as potential crew recovery 
operations, the STS crew will be responsible for 
offloading cargo bay carriers with the RMS; the Station 
crew will use the MSCS to attach them to the Station 
as required. Transfer of payloads within the 
pressurized volume will be shared by STS and Station 
astronauts, which indicates that STS astronauts will 
need to know "basic” information about Station 
systems performance and safety procedures, and vice 
versa. Perhaps as important, for the seven to ten days 
that the STS is docked at the Station, the activities of 
fifteen crew members will need to be planned and 
integrated so as to ensure minimal impact on multi- 
increment, ongoing experiments and optimize 
performance of the expanded crew during this period. 

Space Operations Support 

Space operations support for the Station and STS have 
a number of complementary functions. The command 
and control functions performed by the SSSC and MCC 
are co-located at JSC; interoperability of these 
facilities would provide a valuable backup capability in 


the event of a major support systems failure. Actual 
command and control procedures can also be 
standardized to a great extent, thereby offering the 
potential to move ground operators between the 
Programs with less retraining. (This would also embed 
a higher degree of understanding of operations 
requirements between the two support teams.) 

Payload operations support for the programs also offers 
potential synergies. For example, the Spacelab 
Payload Operations Control Center and the POIC offer 
similar opportunity to develop interoperable and 
standardized user operations support facilities. 
Similarly, payload rack-to-element verification 
activities might be performed utilizing STS support 
facilities such as the Orbiter Processing Facility at 
KSC. 

Finally, crew training, procedures and operations 
techniques development will need to be shared between 
the Programs, with numerous opportunities for joint 
control center and training facilities utilization. 
Specific facilities currently part of the STS Program 
which were identified by the SSOTF as useful for 
Station support include: weightless environment test 
facilities (located at JSC and MSFC); remote 
manipulator development facility (JSC); Shuttle 
mission simulator (JSC); shuttle engineering simulator 
(JSC); vacuum test chamber (JSC); and T-38/KC-135 
acclimation training (JSC). Training schedules for 
these facilities will need to be closely coordinated 
between the Programs to assure the proper support to 
flight crews. (See Section IV.H. Special Topic on Crew 
Training.) 

Other Areas of Synergy 

Another potential area for consolidating operations is 
outside contractor support services. The agency has, 
within the past few years, consolidated a number of its 
O&M and support analysis contracts. (Examples 
include the Payload and Ground Operations Contract 
at KSC, the Network and Mission Operations Contract 
at GSFC, and the STS Operations Contract at JSC.) 
The first attempt to provide SS/STS consolidated 
support is the proposed JSC Systems and Integration 
(S&I) contract which would provide integrated support 
to both Programs for joint training facilities 
development and operations. Further use of such 
consolidated contracting could help to curb operations 
costs and take advantage of the areas of facility 
synergy outlined above. 

IV.F. SAFETY 

Safety requirements definition and documentation will 
be a NASA-controlled function for the manned base. 
Platform safety requirements will be the responsibility 
of the contributing partner. The overall safety review 
process is divided into two major areas: systems safety 
(all Station elements) supported by the Systems Safety 
Panel, and payload safety supported by the Payload 
Safety Panel. The two panels will report to the 
Program Integration level Program Safety Review 
Board (PSRB). The safety certification process for both 
will be similar to the process used in the STS Program, 
except that the PSRB will be chaired by an inde- 
pendent safety officer appointed by the Headquarters 
SRM&QA organization (Code Q). The SSSC will have 
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overall responsibility for inflight operations safety 
controls, while the POIC will be responsible for 
monitoring prescribed user safety requirements. 

Systems Safety 

The systems safety review process will be conducted in 
a similar manner to the STS. This requires that safety 
reviews be held in the same timeframe as design 
reviews (PDR, CDR) for the various Station hardware 
elements prior to assembly. The safety reviews will 
require that each element developer identify all 
hazards associated with that element and how those 
hazards will be controlled. These reviews will be 
conducted for all elements (U.S. and international 
partners) under the direction of the PSRB. 

A Station Systems Hazard Control Plan (SHCP) will be 
required to assure that systems hazards are properly 
handled in the Mature Operations Phase (for systems 
upgrades and hardware additions resulting from 
evolutionary operations). The SHCP development and 
updating will be the responsibility of the Operations 
Flight Director within the SSSC. This plan will be 
developed in a similar manner to the STS Flight Rules, 
and maintained under configuration control once 
baselined. Once approved by the Systems Safety 
Panel, the SHCP is integrated with the equivalent 
payload safety plan by the SSSC and forwarded to the 
Program Safety Review Board for final approval. The 
integrated plan is termed an Increment Hazard 
Control Plan (IHCP). The systems safety review 
process is illustrated in Figure IV- 1. 


Payload Safety 

Ensuring the safe design and operations of user 
equipment in the Station Program will be a significant 
challenge. The quantity of user equipment and variety 
and number of differing payload operations will be 
much greater for the Station Program than for the STS. 
This, coupled with the expected 30-year duration of the 
Station Program, requires that a strong payload safety 
review process be set in place. 

The SSOTF concluded that the Station payload safety 
review process should be similar to the STS Program 
with the following key exceptions: (1) the Program 
Safety Review Board will be chaired by an independent 
safety officer rather than by the Station Program 
(same as in the systems review process); (2) there will 
be a combined STS/Station review process for users 
rather than having users submit to separate Station 
and STS reviews; and (3) there will also be combined 
inflight and ground processing reviews. 14 Features 
which are similar to STS operations include: 

Phased Safety Reviews: The payload is required to 
submit a safety analysis which identifies all hazards 
associated with the payload (both design and 
operation), as well as planned means for controlling 
each hazard. This "data package” will serve as the 
basic means of review by the relevant Program 
organizations involved in the review process. 

Program Involvement: The safety review process must 
involve the appropriate engineering and operations 



Figure IV-1 System Safety Review Process 


14 These last tjvo features are intended to help reduce paperwork and costs to the users in the interest of providing user-friendly 
operations. Additionally , this provides for the development of standardized safety procedures between the Station and STS Programs where 
feasible. 
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organizations of the Program. This includes review by 
the engineering community (SE&I or sustaining 
engineering) for the applicable Station elements in 
which the payload equipment will reside. All 
participating Station operations support organizations 
will support this review process as will representatives 
from the appropriate transportation and data systems 
services organizations. 

Review Board Control: A Payload Safety Panel will 
review all hazard control data submitted by the users 
and recommend changes in payload hardware, software 
and procedures if necessary for safety compliance. The 
Station Program will have the authority to direct that 
these changes be implemented. The various Program 
(and STS) organizations will provide their reviews and 
recommendations to this board. 

The payload safety review process will result in a 
Payload Hazard Control Plan (PHCP) similar to the 
systems plan. Once this plan is approved by the 
Payload Safety Panel, it is sent to the SSSC for 
integration with the SHCP to form the IHCP. This 
process is illustrated in Figure IV-2. 

Operations Safety 

As part of the safety review process, an Increment 
Operations Safety Review will be conducted prior to 
each manned base or platform increment launch. The 
SSSC will be responsible for integrating the systems 
and payload hazard plans into an Increment Hazard 
Control Plan for each increment. The IHCP will 
document all operationally-controlled hazards 
associated with the increment, and the controls which 
eliminate them. 


This plan will require Program Integration level 
approval by the PSRB prior to the increment launch, 
and will be under change control from that point until 
it is replaced by the next IHCP. All procedures or 
operations which involve hazards will require 
warnings in the document which highlight the 
hazardous procedures. Approval by the Operations 
Flight Director will be required to change any 
hazardous procedure or operation once the plan is 
under configuration control. Users will be required to 
demonstrate that their operations procedures comply 
with the hazard control plan, and that all hazardous 
procedures are appropriately flagged. 15 

When possible, hazardous operations should be 
controlled by positive inhibits onboard the Station 
elements. These inhibits could be in the form of 
Operations Management System software inhibits 
which prevent the hazardous operation from occurring 
until it is removed via direct command (remote or 
onboard). Removal of hazard control inhibits shall be 
the sole responsibility of the SSSC for the manned base 
(and platform transfer operations associated with the 
manned base), or the PSC for platform operations. The 
SSOTF concluded that in order to assure direct control 
over all hazardous activity, the enabling/disabling of 
any hazardous operations should not be allowed to be 
automated. Instead, this should require manual 
intervention to assure that a responsible individual has 
reviewed the situation and approved the operation (i.e., 
require positive control). 

Other Issues 

In addition to constructing a recommended safety 
review process, the SSOTF made a number of general 



ls This information will be supplied as part of the PHCP and will be integrated with the SHCP to form the Increment Hazard Control 
Plan. 
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observations on Program safety. In order for the 
review process to be enforced, the Program should 
provide an adequate level of safety indoctrination for 
professional operators (crew and ground personnel), 
users and other support personnel. Only through the 
assimilation of safety requirements and standards by 
those operating the Station elements can a high degree 
of security in operations be ensured. In addition, 
during the Development Phase, contract and Work 
Package incentives are needed to improve safety 
through the proper design of the initial Station 
elements and hardware. The SSOTF felt that such 
incentives would be more effective in improving safety 
factors than would operationally imposed constraints 
on Station activity. 

Finally, the SSOTF concluded that there is a need to 
develop quantitative methodology for performance of 
safety risk assessments. Such methodology would help 
to reduce the dependence on conservative assumptions 
which could unnecessarily reduce operations 
flexibility. As program experience develops, expected 
value estimates and "range of uncertainty” values 
could be used for safety assessments rather than simple 
conservative assumptions. However, for early 
operations the lack of historic data about running the 
Station will require continued reliance on conservative 
assumptions based on previous program experience 
(Skylab and Spacelab in particular). 

IV.G. PRICING POLICY 

Industry experience and the STS pricing policy debates 
have shown that pricing structures can have decisive 
effects on the behavior of providers and consumers of 
complex services. Thus, it is important to assess the 
overall programmatic and political goals that a pricing 
strategy is to accommodate before developing the 
strategy itself. Since these goals are set by agents 
outside of the Space Station Program (primarily the 
Administration and Congress), the Task Force 
examined the effects that different policies would have, 
but did not recommend a particular approach. 

The Task Force identified two possible objectives for a 
Space Station pricing policy which were considered 
most appropriate: 

1) Primary emphasis on recovering NASA funds, 
while encouragingStation use. 

2) Primary emphasis on promoting efficient use and 
management of the Space Station. 

Once the overall goals of the pricing policy have been 
defined, a number of component issues must be 
resolved. In particular, the Program must decide: 1) 
the mechanism by which prices for resources should be 
set; and 2) what resources are to be separately 
measured, monitored and charged to customers. The 
Task Force considered each of these questions in light 
of the two types of overall goals outlined above. 

Types of Users 

For the purposes of discussing pricing policy. Space 
Station users must be broken into several categories: 
users sponsored by NASA and the international 


partners; users from other U.S. government agencies; 
and commercial and non-partner foreign users. The 
applicability of the pricing policy and the means of 
exchange will differ for each of these user groups. 
However, once again, these issues will be determined 
by Congressional and Administration deliberations 
and can be accommodated within the framework 
outlined below. 

Setting Prices 

Cost-Based Pricing Structure 

Federal law requires that agencies offering services 
that offer a particular benefit to one group, individual 
or industry must recover "all reasonable costs” 
incurred in providing these services. Traditionally, 
NASA has interpreted this requirement to mean that 
prices must be based on some measure of actual 
program costs. Such an approach could be used in 
establishing a Space Station pricing policy. One 
alternative would be to allocate Station costs to specific 
services or users and establish prices based on those 
costs. 16 Another would be to charge the user for the 
incremental cost of each service provided. 

Either of these approaches would correspond to 
established tradition, and would permit relatively easy 
accounting procedures and calculations. Furthermore, 
full cost recovery could encourage users to minimize 
their use of particularly expensive services. However, 
such pricing is artificially set and hence does not 
accurately reflect market demand. Therefore, this 
structure does not provide useful information to the 
Program regarding growth requirements. 

Demand-Based Pricing Structure 

A less traditional approach to pricing NASA services 
would be to design the pricing structure to reflect 
demand. Scarce resources would be priced higher than 
those for which there is little demand. Thus power 
required at peak usage times would have a higher price 
than the same power during a period of low-usage. 
Similarly, users would pay for priority: in case of 
interruption or decreases in the availability of 
resources, users who paid for high priority resources 
would receive priority (i.e., uninterrupted) service. 

This approach could be taken one step further by 
establishing an auction or some similar method for 
selling Station resources. Each use class granted a 
resource block by the Space Station User Board could 
put its resources up for bids via an electronic bulletin 
board (or other system), and potential users would bid 
on those resources and time slots which they considered 
most useful. A "floor” or minimum price could be set to 
ensure that minimum cost recovery goals are met, or to 
encourage commercial use while recovering some 
portion of costs. Such a step would prevent the 
Program from selling resources for less than a 
"reasonable” price, and would allow users to plan for at 
least a rough estimate of costs. (They would know that 
costs could be no lower than a certain level.) 


l6 It would be up to Congress and the Administration to determine what costs are to be recovered: full operations cost , full operations cost 
plus developmentcosts, or full program costs. 
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Any of these approaches would improve the 
effectiveness of the pricing structure in guiding Station 
operators in meeting user needs, and in guiding users 
to utilize Station resources. Priority or peak-level 
pricing, in particular, could encourage the optimum 
use of Station resources, while other demand-based 
posted prices would serve as guides to growth. 
Furthermore, a demand-based pricing structure could 
well recoup as much or more of the operating costs than 
a cost-based strategy due to greater and more efficient 
utilization. There are several establishing procedures 
for developing demand-sensitive pricing strategies; 
however, most require extensive information regarding 
user demand, and would need frequent adjustments 
during the early operations phase (a process which 
might not be politically acceptable and would not allow 
confident user planning). 

The auction approach would resolve the issue of 
allocating scarce resources among users, and would 
provide strong signals to the Station operators as to 
which services or resources are most highly valued. 
This information would support efficient operations 
and evolutionary decisions. On the other hand, an 
auction approach would not provide NASA with the 
data required for budgetary planning. It also requires 
that the users be highly involved in and knowledgeable 
about the bidding process (not realistic for small or 
first-time users). Most importantly, the auction might 
eliminate small users from the program, allowing only 
those who can afford to pay high prices to participate. 

Resources to be Priced 

The question of which Station resources are to be 
measured and priced separately will have a strong 
effect on the overall efficiency of the pricing approach. 
On the one hand, measuring and charging for resources 
individually allows greater management control, but 
also incurs a greater management cost. Charging for 
resources in packages or blocks would require less 
ongoing management, but would not allow for close 
monitoring and adjustment in users' actual resource 
demands. 

There are three options regarding this issue: (1) 
monitoring and charging separately for each and every 
resource; (2) monitoring and basing prices on relatively 
few key resources; and (3) establishing prices on some 
other basis. 

The first option is possible because of current plans to 
monitor and protect all interfaces providing resources 
to payloads and Station systems. However, as 
indicated above, costing out and charging for resources 
separately leads to increased management costs (i.e., in 
developing contracts, tracking costs, and billing), as 
well as increased hardware and operations costs (i.e., in 
installing and servicing the necessary monitoring 
equipment, and processing and transmitting the data). 
Furthermore, there are questions of procedure: should 
measurements of a user's resource draw be made on the 
user side of the resource interface, or on the systems 
side? Some resources (like thermal conditioning) may 
not be directly measurable in sufficient detail. 
However, since most of the monitoring equipment and 
procedures will be necessary for other purposes, the 
increased cost may be acceptable. 


Basing prices on one or a few key resources (e.g., power) 
can respond to some of these issues by diminishing the 
number and types of resources which must be 
measured. Such an approach has been used for pricing 
Shuttle services: a user's price was based on either the 
length of the Shuttle bay his payload required or the 
weight of his payload, and this price entitled him to a 
package of "standard” services. However, NASA will 
need to understand the potential demand for Station 
resources in some detail in order to determine which 
key resources should be used as a basis. In addition, 
some method will have to be developed for allocating 
rights to the resources which are not monitored. 

The third option would involve developing prices for 
users which do not refer to actual, measured resources 
usage. Some method of allocating overhead costs could 
be developed, but such an approach would neither give 
the appropriate signals regarding resource use to users 
or operators, nor necessarily be equitable, and would 
represent an abrupt departure from existing policies. 

Early Action Issues 

Because of the effect that pricing can have on user 
payload design and planning, it is necessary that a 
pricing policy be established before major development 
efforts are underway. With a planned Station IOC of 
1995, some payload development efforts will get 
underway in the next several years. As a result, 
development of a Station pricing structure (at least in 
broad outline) should be undertaken immediately. 

IV.H. CREW TRAINING 

This section will detail the key aspects of the crew 
training philosophy, and review what training 
facilities are considered necessary to support Station 
operations. Fundamental to the training philosophy 
for Space Station is a commitment to attain as much 
commonality across the Program as is practical 
between the media, the curriculum, and the facilities 
that will be used for the training in order to minimize 
operations costs. In all instances, this commonality 
will have to be preserved and maintained through 
intensive coordination both between the NASA Space 
Station development centers, and between the NASA 
centers and international partners. As training 
curricula are developed and materials prepared, this 
coordination will have to be rigorously maintained to 
ensure that the most efficient and effective training is 
produced, and that all crew members are sufficiently 
trained to be able to safely and effectively perform 
their respective duties. 

Mature Operations Training Support 

Planning/Scheduling/Coordination 

The planning, scheduling and coordination of training 
activities will be a major task in the Mature Opera- 
tions Phase of Station operations. Training facilities 
and aids will be located at operational centers in all 
parts of the U.S. and at the international partners' 
sites. The possibility for overscheduling of crew 
personnel and facilities is very real. Hence, extensive 
planning and coordination of training activities is 
necessary to prevent conflicts from developing. 
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For the Mature Operations Phase, a joint training 
coordination group is recommended. This Space 
Station Training Coordination Board (SSTCB) would 
be composed of members from all the NASA centers 
supporting Station activities, the international 
partners, astronauts, and safety personnel. This group 
would accomplish the scheduling and conflict resolu- 
tion for all training requirements. The goals of the 
SSTCB would be to provide the following: coordination 
of training schedules and curricula; definition of 
training sources; definition and standardization of 
certification requirements and procedures; definition 
and implementation of commonality requirements; 
definition and coordination of simulation approaches 
and schedules; and definition and implementation of a 
centralized training records system. One of the major 
goals of the SSTCB would be to pursue and maintain 
common training methodologies, media, scheduling 
and execution among all participating organizations. 

It is proposed that commonality in the training process 
be implemented through the following areas: 

Common Training Manuals/Briefings: Documents and 
briefings developed at one center for Space Station 
training could be placed in a common data library 
(accessible through TMIS) where all participating 
groups could access them. This allows savings by 
avoiding the creation of redundant training documents 
or briefings. An additional advantage is that updates 
to a given document would be available instantly at all 
locations. 

Common Computer Aided Instruction (CAP Lessons: 
CAI is an increasingly important training aid in the 
space program. With common CAI equipment located 
at all centers, lessons developed at one center could be 
shared among all and the resource savings could be 
translated into additional or improved training in 
other areas. 

Common Training Equipment: Use of common 

training hardware/software protocols will allow 
transportability of software between centers. The 
same equipment would not be required to be housed at 
each location since the use of common or compatible 
host software means that programs and models 
developed for simulators at one center could be utilized 
at another in a cost effective manner. 

Common Training for Users: With the expectation 
that most Station users will have access to standard or 
common user interface equipment to operate Station 
experiments, a set of common user training standards 
will be developed to allow the most efficient training 
and minimum impact on the user’s time. 

Common Certification Methods: These will be useful to 
ensure that high standards of performance will be 
maintained among personnel at all centers. The 
certification process will include testing of individuals 
to ensure their knowledge for a given task. This 
certification requirement could be applied to all 
personnel in the Station Program, from ground to flight 
crew personnel. 

Common Flight Data File Formats: Common FDF 
formats are used in both systems and payload 
operations. Beneficial reductions in the training 


process would be possible since several different types 
of checklists formats/standards would not have to be 
learned in each area. 

Facilities/Aids 

Briefings and training manuals should be developed 
and shared cooperatively with all participating 
centers. However, the major training facilities will be 
capital investments which must be located to provide 
the maximum benefit to the Program for the lowest 
cost. The major cost issue associated with training is 
the question of centralized versus distributed location 
of the key facilities. 

In terms of convenience and productive use of training 
time, centralized training facilities, collocated with 
trainees where possible, would appear to be the obvious 
choice. This option requires that the appropriate 
hardware (real or mockup) and software be provided 
and maintained at the Space Station Training Facility 
(SSTF). Representative medium fidelity Japanese 
Experiment Module (JEM) and European Space 
Agency (ESA) modules as well as a high fidelity Mobile 
Service Center System (MSCS) trainer would be 
located at JSC in addition to the high fidelity training 
devices located in the respective countries. However, 
the training benefits of centralization are partially 
countered by the cost of maintaining the various 
systems in concert with the "home” configurations and 
the travel required to coordinate such facility 
compatibility. 

Distributed training is also not a perfect solution. 
Although the facility may be located near the persons 
most qualified to do the specific training, coordination 
can become a serious problem as the organization tries 
to keep its training facilities in some common 
configuration. Additionally, students must perform all 
the training integration themselves and consequently 
may encounter problems on-orbit which were never 
presented on the ground due to equipment limitations. 

Both of these options have merit; hence, a mixture of 
both concepts is visualized by the SSOTF. The U.S. 
will provide high fidelity training (using simulators 
and mockups as appropriate) on all U.S. and partner 
distributed manned base space systems in a central 
location. Also co-located with this capability will be 
high fidelity systems training involving crew 
habitation module operations, MSC operations, 
operations within the module interconnect nodes, 
operations within the cupolas, and rendezvous/ 
proximity operations. Additionally, medium fidelity 
U.S. and partner laboratory module simulators will be 
provided at the systems training site in order to 
provide an end-to-end mission operations training 
capability. This group of training equipment is 
referred to as the Space Station Training Facility 
(SSTF). The SSTF will necessarily be located near the 
flight crew offices and near Program personnel 
responsible for integrated space systems operations 
and maintenance. Additionally, training devices 
shared with other programs (e.g., weightless 
environment training facility, Shuttle 1-G Trainer) 
will also be in close proximity to the SSTF. Various 
part-task trainers and training aids will be located 
close to the office areas utilized by the crews for each 
flight increment. 
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Additional high fidelity training for the JEM and 
Columbus module space systems operations 
(distributed and laboratory unique) and payload 
operations will be provided by NASDA and ESA, 
respectively within their operations support facilities. 
Canada will provide a high fidelity MSC simulator 
within its operations support facility. These 
capabilities will be most useful for early space systems 
training of foreign and domestic crew members, for 
training crew members in the operation and servicing 
of foreign user payloads, and for providing an ongoing 
sustaining engineering capability to the Program. 

A high fidelity simulation of the U.S. laboratory 
module and its user support systems will be required as 
well. This simulator will be used for early operator 
training in the operation and maintenance of Program 
provided, laboratory-unique user support hardware 
and software, as well as for training in selected payload 
operations and servicing tasks performed for domestic 
and foreign users. To facilitate integrated manned 
base user operations planning, medium fidelity 
simulators of the Habitation module, nodes, Columbus 
module and JEM will be provided in proximity to the 
U.S. lab simulator. This group of training equipment 
is referred to as the Payload Training Integration 
Facility (PTTF) and will necessarily be located near the 
Program personnel who will develop the U.S. lab 
module and who will provide ongoing user integration 
functions for the Program 


An overview of this partially centralized/partially 
distributed training approach is presented in Figure 

rv-3. 


Combined training between the PTIF or SSTF lab 
module simulators and the POIC will occur on a 
regular basis. It will be here that the main portion of 
the crew’s scientific training occurs after they have 
visited the investigator’s home laboratory. Users will 
need to negotiate with NASA for funding of this 
training related to their experiments. (Only systems- 
related training is full y funded by the Program.) The 
simulator at the PTIF will be maintained in a "next- 
up” configuration (e.g., next increment payload 
complement), while the modules at JSC will be 
maintained in a "current” or "as being flown” 
configuration. There will be a constant flow of these 
experiment configurations from the PTIF, ESA or 
Japan to the SSTF as each flight increment proceeds 
through its training plan. These configurations may 
take the form of software models and of rack 
simulators, each of which will represent an equipment 
rack in the vehicle. A complete listing of training 
facilities and their use is contained in Table IV-2. 


The increment training plans will provide instruction 
for flight crews, ground personnel from all locations, 
and for users. This total training program is 



Figure IV-3 Space Station Crew Training Facilities/Flow 
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JSC FACILITY 


PURPOSE 


1 COMPUTER ASSISTED INSTRUCTIONAL 

TRAINERS (CAIT) 

2* SPACE STATION SYSTEMS TRAINER (SSST) 

3* MEDIUM FIDELITY U S. AND PARTNER LAB 
MODULE SIMULATORS 

4* STATION PROXIMITY OPERATIONS TRAINER 

(SPOT) 

5* FLIGHT CONTROLLER TRAINING ROOM 

FACILITY (FCTR) 

6 SPACE STATION MOCKUP AND TRAINER 
FACILITY (SSMTF) 

7 WEIGHTLESS ENVIRONMENT TRAINING 
FACILITY (WETF) 

8 SPACE STATION SUPPORT CENTER (SSSC) 

9 MISSION CONTROL CENTER-HOUSTON 
(MCC-H) 

10 SYSTEMS ENGINEERING SIMULATOR (SES) 
SHUTTLE MISSION SIMULATOR (SMS) 

1 1 SHUTTLE MISSION SIMULATOR (SMS) 

12 MOBILE SERVICING CENTER (MSC) 
ENGINEERING SIMULATORS 

1 3 MANIPULATOR DEVELOPM ENT FACILITY 
(MDF) 

14 ALTITUDE CHAMBER 

15 KC-1 35 AIRCRAFT 

GSFC FACILITY 

16 EVA TRAINER 

17 INTEGRATION, VERIFICATION AND TEST 
FACILITY 

18 SHUTTLE BAY MOCKUP 

19 PLATFORM SUPPORT CENTER (PSC) 

MSEC FACILITY 

20 NEUTRAL BUOYANCY SIMULATOR 

21 ** HIGH FIDELITY U.S. LAB; MEDIUM FIDELITY 

PARTNER LAB MODULE SIMULATORS 

22 PAYLOAD OPERATIONS INTEGRATION 
CENTER (POIC) 

23 1-G MOCKUP FACILITY 

24 6 DEGREE-OF-FREEDOM SIMULATORS 


SELF-PACED TRAINING USING INTERACTIVE VIDEODISK, 
ARTIFICIAL INTELLIGENCE, ETC. 

DISTRIBUTED LAB AND HAB SYSTEMS, CORE SERVICES 
(INCLUDING NODES AND CUPOLA SIMULATION) 

LAB SYSTEMS TRAINING PLUS EXPERIMENT MOCKUPS 


RENDEZVOUS, PROXIMITY OPERATIONS, MSCS 
SIMULATION 

FLIGHT CONTROLLER DISCIPLINE TEAM TRAINING 


MANNED SYSTEMS, MEDICAL MECHANICAL TIMELINE 
TRAINING 

EVA AND EVA RMS TRAINING 


INTEGRATED SS CREW/GROUND TRAINING 
INTEGRATED STS CREW/GROUND TRAINING 


ENGINEERING, SIMULATIONS. RENDEZVOUS, AND 
PROXIMITY OPS 

SHUTTLE TO SPACE STATION INTERFACE OPERATIONS 

MOBILE MANIPULATOR ENGINEERING AND OPERATIONS 
INTERFACES INCLUDING; STATION, FREE FLYERS, 
PAYLOADS AND STS 

SHUTTLE RMS INTERFACES WITH STATION ELEMENTS 


EVA AND EMU TRAINING 
0-G TRAINING 


EVA TRAINING IN SUPPORT OF PLATFORM 

PAYLOAD, PLATFORM, CUSTOMER SERVICING 
FACILITY, FLIGHT TELEROBOTICS SERVICER. AND LOW 
FIDELITY MSCS PART-TASK TRAINING 

PLATFORM SERVICING TRAINING 

CONSOLE OPERATOR TRAINING FOR PLATFORM 
OPERATIONS 


SELECTED PAYLOAD EVA TRAINING 

LAB SYSTEMS TRAINING PLUS FLIGHT-LIKE 
EXPERIMENTS OR MOCKUPS 

PAYLOAD OPERATIONS CONSOLE TRAINING FOR POIC 
OPERATIONS 

MODULE PART-TASK TRAINING INTEGRATED 
PAYLOAD TRAINING 

PROXIMITY OPERATIONS, TELEROBOTICS TRAINING 
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LeRC TRAINING FACILITIES FOR SSP 

PURPOSE 

25 

ELECTRIC POWER SYSTEM CONTROL 
SYSTEM TRAINER 

SELF-PACED COMPUTER-BASED TRAINING FOR 
ELECTRIC POWER SYSTEM CONTROL SYSTEM 
OPERATORS 

26 

OPERATIONS SUPPORT CENTER (LERC's ESC) 

FULL-SCALE STAND-ALONE AND INTEGRATED 
TRAINING FOR ELECTRIC POWER SYSTEM GROUND 
AND FLIGHT OPERATIONS 

27 

ELECTRIC POWER SYSTEM ORU MOCKUPS 

TRAINING ON FULL SIZE ELECTRIC POWER SYSTEM 
ORU MOCKUPS FOR FLIGHT CREW PROCEDURES 


CANADA FACILITY* 


28 

29 

MANIPULATOR DEVELOPMENT & 
SIMULATION FACILITY (MDSF) 

AIR BEARING TRAINER 

MSCS SYSTEMS AND MALFUNCTION PART-TASK 
TRAINING 

REDUCED FRICTION SIMULATION OF ZERO GRAVITY 
TRAINING FOR MSCS 


ESA FACILITY* 


30 

COLUMBUS MODULE TRAINER 

COLUMBUS MODULE SYSTEMS, MALFUNCTIONS, 
AND PAYLOAD TRAINING 

31 

WATER IMMERSION FACILITY 

EVA RELATED TRAINING 

32 

ESA PLATFORM TRAINER 

PLATFORM OPEF HONS AND SERVICING TRAINING 


JAPAN FACILITY * 


33 

JEM FLIGHT CREW TRAINER 

JEM SYSTEMS AND MALFUNCTION TRAINING 

34 

JEM GROUND TEST MODEL 

JEM SYSTEMS (HI-FI) HARDWARE/SOFTWARE 
TRAINING 

35 

JEM PAYLOAD OPERATIONAL TRAINER 

JEM PAYLOAD OPERATIONS 

36 

JEM RMS TRAINING FACILITY 

JEM MANIPULATOR OPERATIONS 

37 

SPACE STATION INTERFACE SIMULATOR 

JEM/STATION INTERFACE TRAINING 

38 

WATER IMMERSION FACILITY 

JEM PORCH AND RELATED EVA TRAINING 


FACTORIES 


39 

FLIGHT HARDWARE MANUFACTURING 
FACILITIES 

HANDS-ON FLIGHT HARDWARE PART-TASK TRAINING 


PAYLOAD DEVELOPMENT/VERIFICATION 


40 

PAYLOAD EXPERIMENT DEVELOPER 

LIMITED EXPERIMENT HANDS ON AND SCIENCE 
BACKGROUND TRAINING 

41 

PAYLOAD INTEGRATION/VERIFICATION 

PROCEDURES VALIDATION AND EXPERIMENT 
INTERACTIONS 


SPACE STATION 


42 

ON-ORBIT SPACE STATION 

PROFICIENCY TRAINING ON SYSTEMS, RENDEZVOUS, 
PROXIMITY OPERATIONS, MSCS, MAINTENANCE, 
SAFETY EXERCISES AND INTEGRATED SIMULATIONS 
WITH THE GROUND 

‘Comprise the JSC Space Station Training Facility (SSTF) **Comprises the MSFC Payload Training Integration Facility (PTIF) 
*These facilities are understood to be in the planning phase by the International Partners 
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summarized in Figure IV-4. Each group of students 
will receive training proportional to their needs. 

Training Categories 

Three major categories of training systems are 
recommended to be implemented. These are: team 
training; systems training; and payload training. 
Team training applies only to the manned base in 
support of flightcrew activities. Systems training and 
payload support training apply to all elements of the 
Station Program. 

Team Training: This is an integrated training concept 
designed to create teams of personnel at each 
operations center and onboard the manned base who 
can work closely together. The goal with this type of 
training will be to develop behavioral skills in 
teamwork (create a "team feeling” for each increment 
crew and its supporting ground personnel). 


Systems Training: This applies to ground support 
personnel who will be charged with operating the 
Station’s systems. All ground personnel will receive a 
basic introduction to all the elements of the Space 
Station system (including the international 
contributions) via briefings, documentation, tours, etc. 
Additionally, advanced systems training for the 
ground personnel will be conducted in their areas of 
expertise utilizing single system trainers, multi- 
system simulations, mock-ups, etc. Flight Controller 
Training Rooms will be available in the SSOTF to 
support on-orbit systems training without interfering 
with the operations of the SSSC. 

Payload Training: Payload controllers supporting 
payload operations, in addition to being given Station 
systems training as required, will be given specific 
training in payload systems and operations. Once 
again, such training will be user-funded although 
supplied by the Program. Introductory payload 



Figure IV-4 Space Station Student Training Flows 
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training will be provided by the user/payload sponsor 
to include science background briefings, experiment 
objectives, and experiment operations. Payload skills 
will be developed and maintained through separate 
training sessions, during support to payload crew 
training and via integrated and joint simulations. 
Training objectives will be defined jointly by the user 
and the Program, and will reflect the respective 
responsibilities of each ground support position. 


Crew Training Scenario 

As an illustration of how these various training 
programs and facilities will interact to support Station 
operations, the following crew training scenario has 
been developed. (See also the User Integration 
Scenario in Section IQ. D for further detail on training 
interfaces.) 

Career U.S. astronauts (Station Operators and 
Scientists) who have been assigned to the manned base 
will commence with a series of training classes aimed 
at providing them with the requisite proficiency 
necessary to operate the distributed systems on the 
Station. This process will take about six months 
conducted on a part-time basis, and will commence 24 
months prior to launch. This training will occur at the 
SSTF or at other facilities at JSC. 

Once a crew is assigned to a flight increment, they will 
begin a training regimen which will last 
approximately 18 months (e.g., will begin 18 months 
prior to launch). Payload Scientists will be added at 
this point to make up the complete increment crew 
complement. Since they are not career NASA 
astronauts, Payload Scientists will not receive the 
basic Station systems training provided to the other 
crew members. Any systems and habitability (zero-g 
acclimation) training these personnel need will be 
provided later. 

The first six months of increment-specific training will 
be accomplished as a team at the various user facilities 
associated with the team's projected flight increments. 
(Each team will be on-orbit for the duration of two 
increments.) Each individual payload investigator will 
be responsible for the training which the crew will 
receive while at his specific location. Scheduling 
coordination for the crew while taking part in this 
training will be the responsibility of the SSTCB located 
at JSC. 

The following six month s of tr aining will generally be 
based at the POIC or the PTIF where the crewmen can 
work with the investigator’s personnel and with PTIF 
training people versed in the payload problems which 
have occurred on previous flight increments. At this 
point the crew will spend increasing time on individual 
experiments (including brief return trips to the 
laboratories). More and more time will be spent 
operating groups of experiments, which could be 
discipline groupings, or other sets of payloads which 
have some functional affinity. Increasingly, the crew 
will operate in concert with the personnel who will be 
in the POIC and the relevant DOC/ROCs during their 
flight increments. 


About six months before their flight, the crew begins to 
train in earnest in the PTIF with a selected 
complement of experiments. These sessions are 
conducted on an integrated basis with the POIC and 
the applicable ROC/DOCs whenever possible. During 
this time the Station Operators and Station Scientists j 

work on the skills they will require for EVAs planned 
during their increments, and will maintain their 
proficiency with MSCS and other manned base systems 
tasks they will have onboard. 

Three months before flight, the crew moves to JSC 
where their training continues in the SSTF and other 
JSC facilities. The concentration now is on ensuring 
that the crew comes together as a team, and that an 
affinity is also developing between the crew and the 
support personnel who will be on the ground during the 
first few weeks of their flight increment. It is at this 
point that the non-NASA crew members will receive 
the habitability training they require. During this 
period, all of the crew will work to maintain the 
systems skills they will need. 

Beginning approximately ten weeks before launch, a 
small number of integrated simulations will be 
scheduled with a portion of SSSC personnel, along with 
personnel from the POIC and the User’s ROC/DOCs. 

(See Figure IV-5,) These simulations will be designed 
to ensure that the team building process has occurred 
properly and that the training for the increment about 
to launch is properly completed. Finally, after launch, 
M on-the-job” training and proficiency maintenance will 
occur throughout the duration of both increments. The 
entire training cycle for Station Scientists, Station 
Operators and Payload Scientists is illustrated in 
Figures IV-6 through 8. 


Development Phase Training Requirements 

The transition from a development phase orientation 
on assembly tasks to mature Station operations will 
not occur rapidly nor change the basic manner in which 
training is accomplished. Instead, there will be a 
gradual increase in the training load as more 
throughput is required to support the assembly of 
Station elements and the increasing level of user 
activity onboard. It will also be characterized by a 
separation of the STS and Station training operations 
as the Program accelerates and the dedicated resource 
base increases in size. 

During the Station assembly period, training 
responsibilities should be shared between the Station 
and STS Programs. The STS Program should provide 
training support for all activities related to launch, 
rendezvous and docking, and basic assembly tasks (i.e., 
those tasks external to the manned base modules and 
requiring extensive RMS manipulation from the 
Shuttle or EVA) such as truss construction and 
module/node connections. The Station Program should 
be expected to provide training for activities related to 
the internal manned base components activation such 
as module outfitting, equipment verification and 
systems checkout, payload start-up, etc. In any case, 
during the assembly phase very close coordination of 
training requirements and procedures development 
will be necessary. 
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Figure IV-5 Integrated Training For Space Station Data Flow 
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Figure IV-7 Flight Increment Training Cycle — Station Operator 
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Figure IV-8 Flight Increment Training Cycle - Payload Scientist 
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IV.I. SPACE STATION INFORMATION 
SYSTEMS (SSIS) 

The SSOTF Recommended Framework for the manned 
base and U.S. platforms will use the proposed SSIS as a 
key element in planning, managing, and conducting 
orbital operations. Although the Task Force did not 
address operations approaches for the European Space 
Agency platforms, these too will be supported by SSIS. 
The purpose of this section is to briefly describe and 
illustrate the SSIS and highlight differences between 
Task Force recommendations and the currently 
baselined SSIS. 17 


SSIS Definition and Scope 

The SSIS will be an end-to-end data and information 
system for the Space Station Program and its users. It 
is important to understand that SSIS will not be an 
"all-new,” completely dedicated "system” for the 
Program. Rather, the SSIS is better characterized as a 
concept or virtual network consisting of both existing 
and planned operational elements provided by NASA, 
the international partners, and users of the Space 
Station. As defined in the SSIS Architecture Definition 
Document (SSIS ADD), the SSIS supports: 


...the functions of prelaunch checkout, mission 
management, scheduling and control, software 
development, and the acquisition, transmission, 
recording, processing, accounting, storage, and 
distribution of data (including audio and video) 
produced by the Space Station Program, its users, 
and interfacing space and ground elements. 

Although the SSIS is often thought of as only the flight 
critical operational end-to-end information system, it is 
apparent from this definition that the scope of SSIS 
activities is much broader. The SSIS includes real- 
time networks supporting flight activities (commonly 
referred to as "SSIS”, a source of some confusion), and 
non real-time capabilities (i.e., the Technical 
Management Information System [TMIS] and the 
Software Support Environment [SSE]). The 
modifications to SSIS proposed by the Task Force 
recognize this broad scope and supports the concept of 
interoperability among the three systems. 

SSOTF SSIS Architecture: Core Systems and 
Interfaces 

The operational SSIS contains a "core” set of space and 
ground elements. These elements provide the 
functionality required to provide direct support to 
flight operations and interfaces to external elements. 
Figure IV-9 illustrates this concept with the darker 



Figure IV-9 Scope Of The Space Station Information System 


17 The baseline is contained in the SSIS Architecture Definition Document (JSC - 30225). Other relevant SSIS requirements are 
contained in the Space Station Program Definition and Requirements Document (JSC - 30000, Sections 3 and 7) and "Customer 
Requirements for Standard Services Data Book "(JSC * 30221). 
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region representing the operational SSIS. Certain 
systems, such as TMIS and the international partner 
systems, have functional overlaps that are considered 
part of the SSIS core while other systems simply 
interface with SSIS through "gateways” managed and 
controlled by the Program. This Figure also makes it 
clear that the SSIS must be capable of expansion as 
overall Program capabilities evolve. 

The operational sub-networks within the SSIS core 
include onboard data and communications capabilities 
(e.g., Data Management System and Communications 
and Tracking System), ground control systems (e.g., 
the SSSC and POIC for the manned base; the PSC for 
platforms), user ground command, control, and data 
processing facilities (ROCs, DOCs, and UOFs), and the 
communications links between flight and ground 
elements. These links are provided by the TDRSS for 
space-to-ground communications and by NASCOM for 
ground data transport. The interface for the space 
links to the ground links occurs at the TDRS ground 
terminal at White Sands, New Mexico. The Goddard 
Space Flight Center (GSFC) manages and controls the 
TDRSS and NASCOM and provides data transport 
services in response to requests generated by the SSSC 
for the manned base and its users, the PSC for the 
platforms and their users, and the STS Mission Control 


Center (MCC) for the space transportation system, the 
OMV, and their users. Additional network capabilities 
are provided by other users (e.g., the proposed Science 
and Applications Information System [SAIS] for 
NASA’s science users) or by the international partners 
for data transport between their sites. 

Figure IV-10 illustrates a very simple version of the 
SSIS architecture as it will exist to support manned 
base users. Figure IV-11 illustrates a similar architec- 
ture supporting U.S. platforms. The remainder of the 
discussion on SSIS will use the architecture presented 
in Figure IV-10 as a "baseline”; platform operations 
are supported in a similar manner. 

The basic SSIS elements will be provided by different 
organizations both within and external to NASA. 
Additionally, not all of the capabilities required by 
SSIS are dedicated to Space Station activities. (E.g., 
TDRSS and NASCOM support all near-earth orbiting 
NASA spacecraft.) These factors pose complex 
management and integration problems for the 
Program. To assist in resolving these problems, the 
Task Force recognized the need to have a single 
organization responsible for definition and control of 
SSIS architecture requirements. 



SPACE STATION 
SUPPORT CENTER 
(SSSC) 



I 

PAYLOAD OPERATIONS 
INTEGRATION CENTER 
(POIC 


. ' 1 ± ■ -n 

ENGINEERING SUPPORT 
CENTERS (ESC) 

NASA & PARTNER SITES J 



CUSTOMER DATA 

SERVIC fc S DS A F) C,LmES 


T 


DISCIPLINE OPERATIONS 
CENTERS/REGIONAL 
OPERATIONS CENTERS 


T 


USER OPERATIONS 
FACILITY 


USER OR PARTNER SUPPLIED NETWORKS 


Figure IV-lOManned Base SSIS Architecture 


I 


114 


ORIGINAL PAGE 
COLOR PHOTOGRAPH 









Figure IV- 11 Platform SSIS Architecture 


Data Flow Overview 

The SSIS is a critical, and limited, resource in support 
of Program operations. Since SSIS is an international 
network with various elements being provided by 
different organizations, early and effective information 
systems planning is vital to successful operations. In 
developing the CUP, TOP and FEPs, Program system 
requirements and user requirements must be balanced 
against SSIS capabilities to ensure the system is 
correctly configured to provide the necessary end-to- 
end support. 

During Program Execution activities, planning and 
managing the SSIS is a continuous process as new 
users are added/dropped from the configuration and as 
data traffic loads vary with configuration and time. 
The four phases of this process are: controlling access 
to the network; planning processing, collection and 
routing; providing support to users for end-to-end 
connectivity; and overall network management. The 
desired end result of this process is continuous, 
reliable, and "transparent” communications services 
between ground controllers (both system and users) 
and the orbiting elements. This transparency is 
illustrated by telescience operations in which the SSIS 


permits authorized users a direct, real-time 
communications path between the user’s facility and 
the user’s payload. 

Figure IV-12 illustrates the Task Force approach to 
operations planning and scheduling. As illustrated in 
these diagrams, the services provided by both TDRSS 
and NASCOM are treated as "transparent” data buses 
through which all operational data flows between the 
ground and flight elements. The user submits a service 
request to the POIC where all user service requests are 
consolidated and transmitted as an integrated request 
to the SSSC. The SSSC performs an additional 
integration task by consolidating system requirements 
with those of the users. This completed service request 
is then transmitted to the Network Control Center 
(NCC) for implementation. 

Telescience, Access Control, and Safety 

The Task Force fully endorses the concept of telescience 
in support of user operations objectives. 18 As noted 
above, this concept provides the authorized user with 
direct links to the user’s payload. However, this 
approach must be balanced with system and 
operational safety requirements. Safeguards in the 


18 As defined by NASA 's Task Force for Scientific Uses of Space Station (TFSUSS), telescience is * the direct , iterative , and distributed 
interaction of users with their instruments , databases, specimens , and data handling facilities , especially where remote operations are 
essential. " Generally, users desire to conduct operations from their home facilities. SSIS must support telescience activities during preflight , 
flight, and postflight operations. 
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Figure IV-12SSIS Operations Planning And Scheduling 


SSIS will ensure controlled access, and that such access 
will be limited to approved individuals, equipment and 
facilities. The Task Force also recog- ni zed the need for 
positive mechanisms prohibiting the overload of 
critical Station systems as well as developing positive, 
crew-operated inhibits/interlocks for hazardous 
operations (e.g., articulating a telescope during EVA, 
proximity operations, outgassing, servic-ing, etc.) 


A key feature of the telescience concept is the ability of 
users to work freely within negotiated "envelopes.” 
The envelope (one of many onboard data bases) 
describes the resources (e.g., power, bandwidth, crew 
time, etc.) necessary to support a user activity. To 
protect the manned base, the crew, and the user's 
payload, the SSIS must support positive access control. 
There are two types of control. The first simply 
establishes the identity of a user attempting to access 
the SSIS. The second uses predefined tables (the 
envelope) to ensure that the authorized user operates 
approved equipment at approved times, within the 
negotiated envelope. 

Figure IV-13 illustrates the data flow path for the 
commands and return telemetry for such an approved 
user. As illustrated, the SSIS services are provided 
automatically to the user at the scheduled time and no 


additional interaction is necessary between the user 
and the Program control centers (i.e., POIC, SSSC, and 
NCC). The SSIS also supports the transmission and 
onboard execution of Stored Program Commands. In 
this mode of operations, the user develops command 
loads well ahead of the scheduled activity and they are 
executed automatically by the user’s payload at the 
scheduled time. The results of the activity (return 
telemetry) may be either stored onboard or on the 
ground for later delivery or delivered in "real-time” to 
the user’s facility. 

In all cases, the results of the payload activity are 
monitored by an onboard SSIS system: the Operations 
Management System (OMS), 1 ^ Normal, approved 
payload operations are allowed to continue so long as 
they do not exceed the authorized envelope. Payload 
operations exceeding the envelope or causing a 
hazardous drain on available resources will be 
terminated by the OMS. 

To support the development and implementation of 
systems and operational techniques capable of 
supporting telescience, the Task Force developed a 
requirement for a set of end-to-end telescience 
scenarios. These scenarios should be performance 
based models of various telescience operations. 
Developed by the Program with support from the user 


l9 The OMS is, a planned operating system and applications enhancement to the baseline DMS. 
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Figure IV-13Telescience Operations 


community, the scenarios will be capable of measuring 
the performance of alternative information system 
models. The scenarios should include evaluation 
criteria (e.g., performance, cost, risk, etc.) and support 
the assessment of end-to-end command, control, and 
data flow requirements for systems developers. Station 
users, Station system operators, and operations 
planners. These results will then be used as a reference 
baseline against which information systems design and 
information resource management concepts can be 
assessed as the Development Phase progresses and as 
technology evolution studies are conducted. 

Comparison of the Task Force Architecture to the 
SSIS ADD 

As noted earlier, the Task Force SSIS architecture 
differs from that of the currently baselined SSIS ADD. 
These differences are in terms of functional 
capabilities, nomenclature, and locations for various 
ground-based capabilities. Although there were no 
differences for the flight elements, the Task Force did 
make recommendations in several areas (e.g., 
functional requirements for the onboard OMS mass 
storage capabilities, the number and size of TDRS 


antennas, standards and protocols, and the operational 
use of S-band). Some of these recommendations for the 
SSIS are contained in Section V of this report. The 
Space Operations Panel report contains further 
recommendations for SSIS architecture changes. 


Figure IV-14 illustrates the SSIS ADD architecture 
with the facilities proposed for each site. Figure IV- 15 
illustrates the modifications recommended by the Task 
Force. A brief discussion of the major differences and 
the supporting rationale is provided below. Table IV-3 
provides a detailed comparison of these differences. 


As proposed by the Task Force, the user interface will 
be provided by the POIC. In functional terms, the 
POIC provides services similar to some of the functions 
provided by the traditional Payload Operations Control 
Centers (POCC). 20 The POIC will perform user 
planning, coordination, and conflict resolution 
functions replacing this portion of POCC activity. The 
distributed Customer Coordination Center (CCC) and 
Customer Coordination Nodes (CCN) have also been 
deleted with their functions assigned to the POIC. 


20 The POCC is a user facility responsible for planning and conducting payload operations on specific spacecraft. (E.g., each unmanned 
scientific satellite has a POCC as does each Spacelab mission .) 
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Figure IV-14 SSIS ADD Architecture 
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Figure IV-15 SSOTF Recommendations To SSIS ADD Architecture 
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SSIS ARCHITECTURE DEFINITION DOCUMENT: GROUND ELEMENTS 

DATA INTERFACE FACILITY (DIF) 

TDRSS GROUND STATIONS 

INTERNATIONAL GROUND ELEMENT 

DIRECT SUPPORT GROUND ELEMENT 

SPACE STATION SUPPORT CENTER (SSSC) 

SPACE STATION TRAINING FACILITY (SSTF) 

STS MISSION CONTROL CENTER (STS MCC) 

SHUTTLE MISSION SIMULATOR (SMS) 

JSC PAYLOAD OPERATIONS CONTROL CENTER (JSC POCC) 

JSC ENGINEERING ANALYSIS FACILITY (JSC EAF) 

JSC CUSTOMER DATA SERVICES FACILITY (JSC CDSF) 

SOFTWARE SUPPORT ENVIRONMENT (SSE) SYSTEM 

SPACE STATION OPERATIONS MANAGEMENT FACILITY 

CU5 TOMER COORDINATION CENTER (CCC) 

PLATFORM SUPPORT CENTER (PSC) 

DATA HANDLING CENTER (DHC) 

MULTIPLE APPLICATIONS CONTROL CENTER (MACC) 

GSFC EAF 

SSOTF RECOMMENDATIONS 

EXPANDED FUNCTIONS - DIF AT WHITE SANDS (CODE T FUNDS) 

NO CHANGE - AT WHITE SANDS (CODE T FUNDS) 

NO CHANGE - PARTNERS FUND 
NO CHANGE -TBD 
NO CHANGE -AT JSC 
NO CHANGE -AT JSC 
EXISTING ATJSC 
EXISTING AT JSC 

DELETE - FUNCTIONS TO POIC AND ROC/DOC (USERS) 

CHANGE TO ENGINEERING SUPPORT CENTER (ESC) 

NO CHANGE 

NO CHANGE • CODE S FUNDED PROCUREMENT FY87 
DELETE 

DELETE - FUNCTIONS TO POIC 

NO CHANGE -AT GSFC 

EXPANDED FUNCTIONS (CODE T FUNDS) 

DELETE - MISSION OPS FUNCTION IN PSC. SERVICING IN ESC. USER OPS IN ROC/DOC 
CHANGE TO ENGINEERING SUPPORT CENTER (ESC) 

GSFC CDSF 

NO CHANGE 

NASCOM CONTROL CENTER 

(TDRSS) NETWORK CONTROL CENTER (NCC) 

FLIGHT DYNAMICS FACILITY (FDF) 

GSFC CUSTOMER INTEGRATION & VERIFICATION FACILITY (GSFC CIVF) 

EXISTING AT GSFC 
EXISTING AT GSFC 
EXISTING AT GSFC 
DELETE -PART OF GSFC ESC 

DELETE - FUNCTIONS TO POIC AND ROC/DOC (USERS) 

MSFC EAF • • • • 

CHANGE TO ENGINEERING SUPPORT CENTER (ESC) 

MSFCCDSF 

NO CHANGE 

PROGRAM SUPPORT COMMUNICATIONS NETWORK CONTROL CENTER (PSCN CC) 

OMV CONTROL CENTER (OMVCC) 

INTEGRATED LOGISTICS SUPPORT SYSTEM (ILSS) 

MSFC CIVF 

EXISTING AT MSFC (CODE T FUNDED) 

NO CHANGE - CO LOCATE WITH SSSC/MCC AT JSC 
EXPANDED FUNCTIONS - LOCATE AT KSC 
DELETE 

i nor d c\cr 

DELETE - FUNCTIONS TO POIC AND ROGDOC (USERS) 

.oiirEAc CHANGE TO ENGINEERING SUPPORT CENTER (ESC) 

| 4»RC CDSF 

NO CHANGE 

GROUND DATA MANAGEMENT SYSTEM (GDMS) 

EXISTING AT KSC. PARTIAL AT VAFB 

DELETE - FUNCTIONS TO POIC AND ROGDOC (USERS) 


NO CHANGE 

Apr onrr DELETE - FUNCTIONS TO POIC AND ROC/DOC (USERS) 1 

1 ARC CDSF 

NO CHANGE i 

i jor b 

DELETE -FUNCTIONS TO POIC AND ROGDOC (USERS) i 

■ *p rrncc NO CHANGE 

JEM CONTROL CENTER (JEM CC) 

JSCNASDA * 

PARTNER RESPONSIBILITY 

TBD - JOINT CODE S AND NASDA FUNDING POSSIBLE 

ESA INTERNATIONAL PARTNER FACILITIES (ESA IPF's) 

MOBILE SERVICING SYSTEM GROUND SUPPORT (MSS GS) 

CANADIAN POCC 

CUSTOMER FACILITIES (CFs) 

PARTNER RESPONSIBILITY 

NOT DISCUSSED 

PARTNER/USER RESPONSIBILITY 

DELETE - REPLACE WITH ROGDOGUOF (USERS) 

TBD - TMIS LINKS WORK PACKAGE CONTRACTORS 

tuk NO CHANGE -CURRENT CODES PROCUREMENT 

1 NON SSIS INFORMATION NETWORKS (NSSIS) 

USER/PARTNER RESPONSIBILITY | 


NEW SSIS ELEMENTS FROM SSOTF FRAMEWORK 

1. PAYLOAD OPERATIONS INTEGRATION CENTER (POIC) -LOCATE AT MSFC 

2. KSO(VAFB) SPACE STATION PROCESSING FACILITIES (PAYLOAD INTEGRATION AND INTERFACE TEST & VERIFICATION FACILITIES) 

3. DISCIPLINE OPS CENTERS (DOC) - USER RESPONSIBILITY 

4. REGIONAL OPS CENTERS (ROC) - USER RESPONSIBILITY 

5. USER OWNED FACILITY (UOF) - USER RESPONSIBILITY 

6. LOGISTICS OPERATIONS CENTER (LOC) * AT KSC 

7. TBD SSIS INTERFACES TO “SCIENCE AND TECHNOLOGY CENTERS" TO SUPPORT PAYLOAD/RACK BUILD, TEST, AND VERIFICATION 


Table IV-3 Comparison Of SSIS ADD And SSOTF Recommendations 


While the Program has taken responsibility for 
coordinating user activities in the POIC, direct payload 
operations support is till a user responsibility. These 
functions are performed in the user-provided DOCs, 
ROCs, and UOFs. The DOCs, ROCs and UOFs thus 
replace the Customer Facilities (CF) in the SSIS ADD 
architecture. 

Other functional changes include eliminating the 
GSFC Multiple Applications Control Center (MACC). 
User support activities proposed for the MACC are now 
to be performed in DOCs, ROCs, and UOFs. The 
Servicing Support Center (SSC), attached payload 
engineering support, and Flight Telerobotics Servicer 
(FTS) engineering support functions are moved to the 
GSFC Engineering Support Center (ESC). 


In addition to these overall Task Force recommenda- 
tions, the Space Operations Panel developed further 
recommendations on modifications and refinements to 
the SSIS architecture. The first deals with the data 
interface capabilities at the TDRS ground terminal site 
in White Sands, New Mexico. The Space Operations 
Panel recommended enhancing the Data Interface 
Facility (DIF) capabilities for data relay, repackaging, 
format conversion, and data buffering. 


This panel also suggested additional operational 
requirements for the planned Data Handling Center 
(DHC). The current DHC concept calls for a "no value- 
added” preprocessing of NASA engineering and science 
data (commonly referred to as Level Zero Processing). 
The Space Operations Panel also developed additional 
requirements in the areas of preprocessing for all 
manned base, platform, and payload data (including 
voice and TV/Video), "quick-look” data processing and 
routing, and a store and forward function for non- 
critical payload and engineering data. Since both the 
DIF and DHC are to be funded and managed by 
NASA’s Office of Spaceflight Tracking and Data 
Systems (OSTDS), the implementation of these 
recommendations must be studied and mutually 
agreed upon by the Program and OSTDS. 

IV.J. SPACE STATION MANAGEMENT 
INFORMATION SYSTEMS 

The operations framework proposed by the Task Force 
features an internationally staffed, integrated 
operations management team. This team will manage 
and control the Program from a central operations 
office at NASA Headquarters. Program execution is 
distributed to NASA and international partner sites. 
Implementing the Framework will require strong 
organizational relationships among the various 
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locations and an equally strong and centrally managed 
set of information management tools and systems. 
This section provides an overview of the Space Station 
Management Information Systems (MIS) functions 
necessary to support the Recommended Framework. 

In providing these support systems, there are three key 
tasks to be completed before beginning their actual 
development and implementation. These are: (1) 
describing the use of the systems (i.e., "what” are the 
jobs to be performed and "how” are they to be 
performed?); (2) defining the data and information 
needed to perform the job (further refinement of "how” 
jobs are performed which includes identifying sources 
and destinations of data and information as well as 
defining the functional capabilities of the systems); and 
(3) developing and implementing effective information 
management controls. 

The first and second tasks are highly iterative in 
nature. Completion of these tasks results in a 
functional description of the jobs, a top-level approach 
to performing them, and top-level functional 
requirements for the systems. The third task will be 
especially challenging for the Program. Given the 
distributed nature of much of the information, the 
development of the management controls may be more 
difficult than development of the systems. 

Database Categories and Uses 

This section suggests areas in which MIS is required to 
support overall Program management. It uses as a 
starting point the work of the Technical and 


Management Information System (TMIS) project and 
the surveys and analyses performed to define the scope 
of this system. 21 As a result of the TMIS Information 
Analysis task, 28 top-level, key database categories 
were developed. These are illustrated in Table IV-4. 

A review of this table reveals that the database 
categories support the majority of the basic operations 
functions (described earlier in Section ID) used by the 
Task Force to develop the Recommended Framework. 
However, most require further definition in order to 
describe the job to be performed in support of the 
Framework. 

For example, Figure 1H-3 illustrates the Recommended 
Framework’s planning and control hierarchy. 
Utilizing this as a baseline, a follow-on task to be 
completed by the Program is the more detailed 
description of the operations and utilization planning 
job. Therefore, Item 25 in Table IV-4 (Operations) 
must have at least four separate operations and 
utilization planning databases (or at least four 
separate levels of hierarchical detail) to correspond to 
the four levels of planning identified by the Task Force. 
While the Task Force has developed "strawman” tables 
of contents for the major plans (i.e., the CUP, TOP, 
FIPs, and execute plans), details of "how” the planning 
process will be completed are yet to be defined. 2 


In this hierarchy of planning, the tactical level 
provides a good example of the data exchange that 
must take place. A key product in the Tactical 
Operations Plan are the multiple increment manifests 


TMIS will provide integrated system capabilities to support 28 major Program technical and 
management processes identified through the TMIS Project's information analysis tasks. These 
processes are listed below. 


1. BUDGETING 

2. PLANNING 

3. SCHEDULING/PROJECT MANAGEMENT 

4. POLICY DEVELOPMENT 

5. PERFORMANCE MEASUREMENT 

6. TECHNICAL CONTRACT MANAGEMENT 

7. ADMINISTRATIVE CONTRACT MANAGEMENT 

8. PROGRAM REVIEW 

9. EXTERNAL AFFAIRS 

10. INTERNATIONAL RELATIONS 

11. CUSTOMER RELATIONS 

12. REQUIREMENTS ANALYSIS 

13. TECHNICAL ANALYSIS 

14. INTERFACE CONTROL 


15. COST/FINANCIAL ANALYSIS 

16. DESIGN 

17. DESIGN REVIEW 

18. ACQUISITION 

19. ADMINISTRATION 

20. IMPLEMENTATION AND INTEGRATION 

21. TEST AND VERIFICATION 

22. DOCUMENTATION 

23. CONFIGURATION MANAGEMENT 

24. TRAINING 

25. OPERATIONS 

26. MAINTENANCE 

27. PROTOTYPING 

28. INVENTORY MANAGEMENT 


Table IV-4 Space Station - Key Databases 


21 The TMIS is being procured by NASA as a mechanism to support the Program 's development and mature operations activities. 

22 The detailed contents of many of the Operations Execution Plans will either be derivatives of current STS and unmanned spacecraft 
operations plans or are in the definition stage . While the Task Force did not specify the contents of these detailed plans, it did suggest 
several databases (both on orbit and on the ground) which would contribute to development of these plans or would be the repository of 
plans. See Tables IV -5 and IV -6 in this section. 
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for transportation systems, payloads, and logistics 
cargo. With logistics and transportation systems as 
primary drivers of the Tactical and Flight Increment 
Planning processes, the MIS must contain detailed 
databases containing multi-increment information 
such as logistics requirements, status of consumables 
and spares, payload requirements, SR&QA hazards, 
maintenance schedules, transportation availability, 
test and integration schedules, top-level and detailed 
ground processing flows and critical path analyses of 
the end-to-end logistics and transportation schedules. 
Additional databases are required to support 
programmatic activities such as scheduling, budgeting, 
and configuration control. 

Given the complexity of the manifesting process and 
the numbers of variables involved, it also appears 
necessary to provide tools based on operations research 
technologies to enable planners to perform trades 
among the variables affecting each increment plan, for 
example, there are finite test and integration 
capabilities at the launch site. There are also finite 
storage areas for payloads and cargo either awaiting 
checkout or those that have completed checkout and 
are waiting to be integrated into the launch vehicle. 
Developing optimum schedules for the flow of this 
material through the launch site facilities is a typical 
operations research problem. Another example where 
this type of technology will prove useful is in the 


management of changes to manifests. For instance, if a 
manifested payload (with certain mass, volume, and 
power requirements) cannot be delivered as originally 
scheduled, what substitute payload(s) can be inserted 
into that particular launch schedule with the 
minimum of impact on orbiter processing flows, orbiter 
and payload Flight Data File preparation activities, 
Space Station operations, and user operations? 

These examples illustrate the iterative nature of 
defining usage along with describing the types of 
information necessary to perform the manifesting 
function. The next step is to define the details of the 
data, sources and destinations of data and information, 
and database structures. These must all be completed 
before database development can begin. 

Potential Databases for Space and Ground 
Operations 

The Task Force identified several potential databases 
for both orbiting systems and ground systems. These 
are listed in Tables IV-5 and IV-6 respectively. As can 
be seen from these candidate lists, there is a wide range 
of data and information necessary to support the full 
scope of Program operations. Key among these will be 
hierarchically consistent data sets of operations 
performance, cost performance, and program risk 


DATABASES APPLICABLE TO 
MANNED BASE AND PLATFORM 

DATABASES APPLICABLE TO 
MANNED BASE ONLY 

• Payload Characteristics 

Resource requirements, servicing requirements, constraints, restricted 
operations 

• Operational Event List 

Combination of schedule and stored transactions 

• Payload Fault Isolation Data 

Diagnostic programs, executable procedures, operational procedures 

• Payload/Systems Operational Procedures 

Nominal and malfunction-executable procedures, operational procedures 

• Application Software Loads 

Core/system elements, payload elements 

• System Software Loads 

SDP software, NIU software, MPAC software, display templates 

• Master Schedule 

Short term 

• Payload Status 

• Core Subsystem Status 

• Navigation Data 

Ephemeris: SS, TDRSS, COP, free-flyers, GPS, OMV. NSTS, platforms 

• Software Configuration Management Data 

• Hardware Configuration Management Data 

• Ancillary Data 

Core and user induced 

• Instrumentation/Measurement List 

Core and Payload 

• Buffered Recorder Data 

• Configuration Data 

Address mapping tables, authorization tables, constraint tables, 
expendable resource capacity 

• Fault Isolation Rules 

List of rules, recovery procedures 

• Security/Privacy 

Commercial, technology transfer 

• Payload and System Training Procedures/Simulations for Skills Retention 

• On-orbit Checkout Procedures 

• Servicing Procedures and Servicing Element Characteristics 

STS, OMV, OTV, EVA/IVA, MSC, free flyers 

• Crew member Data 

Medical profiles, confidential/personal, medical facility 

• Safehaven Procedures 

• Security/Privacy 

Crew. DOD 

• Master Schedule 

Long Term 

• Inventory 

Consumables, spares 

• Payload Fault Isolation Data 

Description diagram 


Table IV-5 Candidate On-Board Databases 
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GROUND DATABASES IDENTIFIED IN TMIS RFP 

• Reference Configuration (REFCON) 

• Mission Requirements (MRDB) 

• Engineering Drawing 

• SR & QA Hazards 

• SR & QA Safety Requirements Compliance 


• Scheduling Database 


[ OTHER POTENTIAL GROUND DATABASES 

• Operational Procedures 

Nominal and Malfunction 

• Operational Restrictions, Notes, and Wavers 

• Payload Manifests 

• Systems Operations Timelines 

• User Operations Timelines 

• Crew Activity Timelines 

• Integrated System/User Operations Timelines 

• Core and Platform Systems Resource Allocations 

• Core and Platform User Resource Allocations 

• User/Systems OPS Access Control Tables 

• Command Formats 

• Predefined Command Sequences 

• Event/History Logs/Diagnostic Trials 

• Payload/Instrument Configurations 

• Onboard Data Channelization Systems and Payloads 

• Telemetry Calibration, Data Types and Units 

• Master Measurement List 

• Systems Monitoring Limit-Sets and Limits 

• Ground Systems Configuration Management 
Hardware and software 

• Onboard Systems Configuration Management 
Hardware and software 

• Network Configuration Management 

Hardware and software 

• Logistics Inventory 

• Manned Base and Platform Ephemerides 

• Ancillary Engineering Analysis Data 


TableIV-6 Ground Databases 


assessments. Other databases capturing the "design 
knowledge” of the development Centers and their 
contractors must also be established and maintained 
throughout the Development Phase. These data will be 
used in analyses supporting near-term operations 
management as well as developing plans for evolution 
of Station elements. 


Management and Control 

While the Recommended Framework calls for 
Headquarters control, it is important to recognize that 
the majority of the information necessary for the 
Headquarters organization to perform its tasks resides 
at the distributed NASA, partner, and user operations 
centers. As a result, the Task Force developed 
recommendation and requirements for Program level 
management and control but left the details of the day- 
to-day control of data and database operations to these 
distributed centers. 

One of the most critical requirements to be established 
by the Program will be the accuracy and timeliness of 
information contained in the databases. The 
information in each must be rapidly updated as 
changes occur. Key relationships among data sets 


must be established so that planners and operations 
managers will have immediate notice of and access to 
changes, regardless of the location of the changes. The 
relationships must also identify the impact of changes 
on the overall planning and flight increment 
management process. 

This implies that access to most databases must be 
available at each of the distributed execution locations 
as well as at NASA Headquarters. Control over that 
access and control over changes to the contents of each 
database resides with the center or office responsible 
for individual databases. To amplify this point, it 
should be possible for an authorized user to make a 
copy of a data set, manipulate the data, and or delete 
data from the copy, perform analyses, produce reports, 
etc. However, no user should be permitted to make a 
permanent change to the data or to the database 
operating system without approval of the responsible 
database manager. 

Ready access to data and information can be most 
effectively accomplished through Program-wide 
definition of database standards. It is essential to 
define common data types and characteristics. 
However, dissimilar database architectures may be 
used to support specialized functions if the data 
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characteristics are preserved across interfaces and 
translations among databases. Thus, the design goal 
for SSP databases should be to ensure commonality and 
uniformity of data sets, units of measure, and 
representation formats (both data content and level of 
detail) without constraining programming languages 
and user interfaces. This will be particularly 
important as the Program seeks to achieve 
interoperability among the operational SSIS, TMIS, 
SSE, and other existing data and information systems. 


As noted in the introduction to this section, TMIS and 
other systems such SSE, can provide some of the tools 
and connecting systems necessary to perform the task, 
but it will be the responsibility of the various Program 
and Center organizations to actually develop the 
databases, enter the data, and perform database 
maintenance and control. The Program will also have 
to develop special tools, such as the operations research 
tools mentioned above, independent of TMIS and the 
Phase C/D Work Package contracts. 



V. RECOMMENDATIONS FOR 
IMPLEMENTATION 


The following list comprises the official recommenda- 
tions of the SSOTF. They fall within five broad 
categories: (1) Program Operations Management 
Recommendations; (2) Space Operations and Support 
Recommendations; (3) User Integration and Accommo- 
dation Recommendations; (4) Logistics Operations 
Support Recommendations; and (5) Systems Develop- 
ment Recommendations. The first four categories 
contain recommendations pertaining to implementa- 
tion of the operations framework as described in this 
Summary Report; the fifth category contains several 
systems "design-to" type recommendations derived 
from the individual panel reports and are fully 
supported by the SSOTF. 

Additional panel recommendations pertaining to the 
detailed implementation of the various operational 
issues addressed during the term of the SSOTF may be 
found within the individual Panel Reports. Implemen- 
tation of these detailed recommendations should be the 
prerogative of the appropriate operations support 
organizations once the overall Station Operations 
Organization is established. 


V.A. PROGRAM OPERATIONS MANAGEMENT 


1 . Immediately baseline the Space Station operations 
framework as described in this SSOTF Summary 
Report. Appropriately revise existing Program 
documentation to reflect this baseline. 

2. Implement the Station operations management 
organization structures for the Development and 
Mature Operations Program phases as detailed by 
the SSOTF Summary Report (reference Figures 
m-26 and III-25, respectively), including the 
following highlights: 

A. Separate utilization and operations organiza- 
tional and budgetary functions from space 
systems development and budgetary functions 
at the Program Integration level for transition, 
and the Associate Administrator level for 
mature operations 

B. Establish the Office of Director, Utilization and 
Operations at the Program Integration Level. 

C. For mature operations, provide an Increment 
Change Management Office at the Program 
Integration Level to manage all aspects of 
preflight planning with the delegated authority 
of the Director, Utilization and Operations. 

D. Identify the organizational elements as well as 
the Program control and support responsi- 
bilities at each management level. At the 
Program Execution level, allow implementa- 
tion flexibility with regard to project vs. matrix 
support structure. 


3. Implement the following NASA support center 
functional assignments: 

A. Program integration and control: NASA Head- 
quarters. 

B. For the manned base, user operations focus, 

including the integration of user operations and 
servicing requirements and plans: the 

Marshall Space Flight Center (MSFC). 

C. For the manned base, space systems operations 
focus, including the integration of space 
systems operations requirements with KSC- 
provided ORU maintenance requirements and 
MSFC-provided user operations and servicing 
requirements into executable and safe plans 
and procedures: the Johnson Space Center 
(JSC). 

D. For the manned base and platforms, integra- 
tion of logistics operations support require- 
ments and plans: the Kennedy Space Center 
(KSC). 

E. For the U.S. platforms, integration of all space 
and user systems requirements and plans: the 
Goddard Space Flight Center (GSFC). 

F. For the manned base and platforms, provision 
of sustaining engineering for the orbiting 
elements and systems: the Lewis Research 
Center (LeRC), MSFC, JSC, GSFC and KSC as 
appropriate to Program responsibilities for 
element and systems development. 

4. Develop specific implementation requirements, 
plans and schedules for the ground facilities which 
the SSOTF recommends for Space Station opera- 
tions support, to include: 

A. Construction of a phasing plan that identifies 
those facilities which are mandatory to support 
first element launch and those whose readiness 
may be phased in to support subsequent 
assembly operations. 

B. Identification of requirements, if any, for those 
facilities which the SSOTF identified as ques- 
tionable. 

C. Inputs to the construction of facility (C of F) 
process including schedules and priority assign- 
ments. 

D. Development of a cost-sharing approach 
between the STS and Space Station Programs 
for those facilities which are shared. 

E. Identification of those Station Program facili- 
ties built to support the Development Phase of 
the Program which will be required to support 
ongoing sustaining engineering operations. 
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5. Establish and document the Program configura- 
tion control processes at each organizational level 
as required to implement this SSOTF Operations 
Framework. Further develop the content, scope 
and framework for the Consolidated Utilization 
Plan, the Tactical Operations Plan, and the Flight 
Increment Plans, and determine specific organiza- 
tional responsibilities, interface protocols, infor- 
mation systems requirements and schedules for 
their production and review. 


6. To facilitate Program operations life cycle cost 
projections: 

A. Conduct an operations costs estimation study 
with each participating operations organization 
using the center assignments, facility require- 
ments and overall operations framework 
described in this Summary Report. 

B. Develop a process for estimating annual opera- 
tions costs which accounts for all elements of 
the operational framework as described within 
this Summary Report. 

7. Ensure that the Program Integration level (NASA 
Headquarters) of the Station Operations organiza- 
tion retains control of the overall SSIS archi- 
tecture, including SSIS interface with both the 
TMIS and SSE operational support systems. This 
includes control of all requirements affecting the 
various nodes of the SSIS network. Further, to 
ensure SSIS interface compatibility with user tele- 
science requirements, a user telescience scenario 
should be developed by the Program as a reference 
against which SSIS capabilities can be assessed 
and technology trades conducted. 

8. The SSOTF emphasizes the need for development 
of a TMIS that fully supports all aspects of this 
operations framework during each Program phase. 
The technical and political difficulty of achieving 
present and future interoperability between NASA 
and partner operations support centers, and 
between the Space Station and STS Programs, 
represents a significant Program challenge which 
must receive the early and continued attention of 
top NASA management. Crucial to the success of 
such an effort is the early identification of the 
various Program databases (engineering and 
operations) required to support the Program's 
Development Phase; these databases will serve as 
the point of reference for each organizational level 
as the Program transitions to the Mature Opera- 
tions Phase. 

9. Develop an equitable policy regarding sharing of 
operations costs among the partners. This policy 
must be straightforward and easily implemented 
and should consider individual partner resource 
allocations, sustaining engineering responsibili- 
ties, and overall contributions to routine Station 
operations. 

10. Develop an equitable pricing policy for utilization 
of Station resources. This policy must be straight 
forward and easily implemented and should cover 


the variety of anticipated government and non- 
government users of the Station, both domestic 
and foreign. 

11. Upon joint approval of the NASA/partner MOUs 
regarding international cooperation in the Space 
Station Program development and operations 
phases, immediately begin to integrate interna- 
tional participation at all levels of the operations 
organization. 

12. Establish an operations performance assessment 
system available to each level of Program 
management which identifies symptoms of non- 
optimal performance as well as decision path 
alternatives which, if implemented, could improve 
ground and onboard operations effectiveness. 

V.B. SPACE OPERATIONS AND SUPPORT 

13. Baseline the following criteria relative to flight 
crew composition and skills emphasis: 

A. The Director, Utilization and Operations, shall 
have final approval authority for selection of all 
manned base crew members. 

B. The manned base shall have a commander who 
is a NASA career astronaut. 

C. Manned base crew members shall be assigned, 
trained and integrated on board as an inte- 
grated team. 

D. Scientific credentials shall be considered 
paramount when selecting candidates for 
Station Scientist positions. 

14. Immediately establish a multicenter/ multina- 
tional Training Coordination Board to integrate 
advanced planning activities associated with the 
use of all crew training facilities supporting the 
Space Station Program. 

15. U.S. and ESA Platform operations planning should 
be the sole responsibility of the sponsoring partner 
below the Program Policy (strategic planning) 
level. Further, the platforms should operate inde- 
pendent of each other and of the manned base, 
except for proximity servicing operations of co- 
orbiting platforms at the manned base. 

16. Ensure that there is a full backup capability to the 
Station ground command and control network to 
cover environmental and technical contingencies 
affecting routine Station operations. 

17. The Program should develop a single element loss 
and recovery program plan applicable to the 
assembly phase. 

V.C. USER INTEGRATION AND 

ACCOMMODATION 

18. Establish an independent (external to the Station 
Operations organization) U.S. Space Station User 
Board (SSUB), reporting to the NASA Adminis- 
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trator and supporting the Associate Administrator 
for Space Station Operations in strategic planning 
for Station utilization. Membership on the SSUB 
should be at the Associate Administrator (or 
equivalent) level as determined by the NASA 
Administrator, and responsibility for chairman- 
ship should rotate annually among member 
organizations. Additionally: 

A. Develop NASA policy for the SSUB charter 
including specific protocols for its interface 
with the Space Station Program. 

B. Encourage each international partner to 
establish an analogous user board with similar 
functions and protocols for interface with the 
Space Station Operations organization. 

C. Establish the SSUB process for allocating U.S. 
and partner resources to the various Station 
user sponsors. 

19. To facilitate user accommodation and integration 
within the Program, provide a cadre of Payload 
Accommodation Managers (PAMs) accountable to 
the Program Integration level (NASA Head- 
quarters) of the Operations organization. Each 
PAM will be a senior utilization and operations 
advocate who will serve as the primary liaison 
between each selected user, the Station and the 
appropriate transportation system program. 

V.D. LOGISTICS OPERATIONS SUPPORT 

20. Asa means of reducing Station dependency on the 
STS: 

A. Provide an independent means of Station crew 
recovery which satisfies Program requirements 
for accommodating on-board medical contin- 
gencies as well as for rescue of the total Station 
crew. 

B. Provide an independent means of logistics 
support to the Station. Study the feasibility of 
the following as potential "design solutions": 

— Independent cargo return: STS-launched 

logistics carrier with either a recoverable 
ballistic or a controlled atmospheric destruction 
reentry capability; 

- Independent cargo resupply and return: ELV 
launched logistics carrier with an auto 
rendezvous and/or OMV retrieval capability, 
and either a recoverable ballistic or a controlled 
atmospheric destruction reentry capability. 

C. Perform cost trades on "throwaway" versus 
STS-serviceable polar platforms. 

D. Perform cost trades on standard versus non- 
standard ORU and payload interfaces for STS 
and ELV launch vehicles. 

21. Establish a distributed approach to payload inte- 
gration which allows: 


A. Payload-to-rack and payload-to-PIA integra- 
tion and functional operations verification at 
Program-designated NASA and partner 
Science and Technology Centers. 

B. Rack-to-element integration and interface 
verification at the launch site. 

C. Integrated operations end-to-end checks on- 
orbit. 


22. Initially establish a distributed approach to space 
systems sustaining engineering which allows: 

A. Space systems sustaining engineering perform- 
ed by appropriate NASA and partner develop- 
ment centers as defined in Table III-7. (For the 
U.S., this represents the Development Phase 
work package assignments.) 

B. NASA Headquarters coordination at the 
Program Integration level. 

C. Gradual centralization of U.S. orbiting 
elements sustaining engineering functions at 
KSC, commensurate with Program manage- 
ment determination that the corresponding 
space systems have reached their performance 
maturity. 

V.E, SYSTEMS DEVELOPMENT 

23. Add a second Ku-band system on the manned base 
as a backup to normal operations and to enhance 
operability by minimizing TDRS hand-over 
dropout. 

24. Increase Ku-band antenna size or radiation power 
to accommodate full forward link TDRS bandwidth 
of 25 mbps, or provide effective TV compression 
techniques within the available reduced band- 
width. 

25. Provide for operational use of S-band and consider 
assignment of critical manned base systems and 
crew operations functions to this band. This would 
provide for interoperability with international 
relay satellites and improve partner communica- 
tion links. 

26. Conduct trade studies to establish the potential for 
ground-based operators and users to have 
"continuous acquisition of signal" with the 
Station's manned base. 

27. As a means of facilitating evolutionary orbital 
operations, develop the following additional capa- 
bilities which are beyond current baselines: 

A. Increase allowable crew stay time through 
development and implementation of a medical 
flight duration extension program. 

B. Expand the on-board environmental monitor- 
ing capability and electronically link to the 
manned base Health Maintenance Facility. 
The system should be capable of quantifying 
biohazards and microbial loads. 
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C. Investigate methods of safely increasing STS 
passenger capacity. 

28. The Program should provide additional racks as 
required to support the distributed payload inte- 
gration concept; the number of currently baselined 
racks appears to be insufficient. Additionally, rack 
and PIA level simulators should be provided to 
each Science and Technology Center to facilitate 
standardized payload-to-rack and PIA integration 
and verification. 

29. Provide a capability for late pad access to logistics 
module pressurized volume (e.g., side hatch, access 
port). 


30. To the maximum extent possible, the Station 
Development Program should achieve space 
systems "fit and function" commonality across all 
Station elements. Commonality is an effective 
means of reducing the operational complexity of 
performing Station logistics and on-orbit house- 
keeping tasks, thereby increasing potential for 
user accommodation. Commonality criteria should 
be developed early in the development Phase of 
the Program and, subsequently, be formally 
controlled at the Program Integration level. 


128 



APPENDIX A 



APPENDIX A 

SSOTF Composition and Background Briefings 

The following material presents the complete listing of members, participants and supporting consultants in 
the Space Station Operations Task Force. The SSOTF membership was divided into four panels, chaired by panel 
leaders, each with an area of specific emphasis. The four panels were: (1) Space Operations and Support 
Systems; (2) Ground Operations and Support Systems; (3) User Development and Integration; and (4) 
Management Integration. Space Operations incorporated all operational components of the Program which 
provide the planning, training, and operational management for the conduct of on-orbit activities. Ground 
Operations encompassed all components of the Program which provide the planning, engineering and 
operational management for the conduct of integrated logistics support (logistics, sustaining engineering, 
pre/post-launch processing and transportation services). User Development encompassed all areas of the 
Program related to user accommodation and integration activities (marketing, manifesting, user selection and 
pricing). Management Integration included all SSOTF internal concept integration and analysis coordination 
(methodology development, operations functions definitions and scenario generation) required to provide an 
integrated operations framework. 

In addition to the NASA members on these panels, a number of external participants supported the SSOTF in 
varying degrees. These included members of industry, NASA Center Directors and key Headquarters personnel, 
and participants from outside NASA (Air Force SR-71 Program, U.S. Navy Trident Submarine Program, and 
British Navy Submarine Operations). A number of firms also briefed the Task Force on various aspects of 
operations. Finally, the SSOTF employed support contractors to aid in the report preparation and integration 
activity. All these participants and their contributions are listed on the following pages. 


PANEL MEMBERSHIP 


PANEL 1 

Space Operations 
and Support Systems 

PANEL 2 

Ground Operations 
and Support Systems 

PANEL 3 

User Development 
and Integration 

PANEL 4 
Management 
Integration 

‘John T. Cox 

JSC 

♦Charles Mars 

KSC 

♦George Anikis 

HQ/MC 

♦Granville Paules 

HQ/SO 

Anne L. Accola 

JSC 

Judy Anderson 

KSC/VAFB 

Laura Crary 

JPL 

Kevin P. Barquinero 

HQ/S 

Lawrence S. Bourgeois 

JSC 

Barbara Arnold 

DoD/OASD 

William Gray 

JPL 

Daniel A. Bland 

JSC 

Robert L. Bowman 

LeRC 

Dick Bohlmann 

KSC 

Carolyn Kimball 

HQ/S 

Karen Brender 

LaRC 

Walter Bradley 

GSFC 

Charles Bunnell 

MSFC 

Deborah Langan 

JSC 

Johanna A. Gunderson 

JSC 

Robert S. Clark 

JSC 

Bonnie P, Dalton 

ARC 

Lisa Mann 

ARC 

Joseph Joyce 

LeRC 

Romo Cortez 

HQ-T 

John Ewashinka 

LeRC 

Larry Milov 

ARC 

Douglass Lee 

DOT 

Anthony W. England 

JSC 

James Kelley 

KSC 

John Mitchell 

JSC 

Richard O'Toole 

JPL 

Carolyn S. Griner 

MSFC 

Kam Kersey 

KSC 

Dave Porter 

JPL 

William Pegram 

HQ/SU 

Mike Hawes 

JSC 

John McBrearty 

KSC 

William Roberts 

MSFC 

Robert Shis hko 

JPL 

Frank E. Hughes 

JSC 

Roland (Mack) McCartney KSC 

Jeff L. Smith 

JPL 

Gregory Williams 

HQ/SO 

Richard Koos 

JSC 

Robert J. Manly 

LeRC 

Olav (Ole) Smistad 

JSC 



Richard Laeser 

JPL 

Jim Mizell 

KSC 

Nicholas Talluto 

KSC 



Charles M. Lewis 

MSFC 

James W. Moore 

MSFC 

Richard Tyson OAST/LaRC 



James S. Logan 

JSC 

Danny F. Nail 

KSC 

Don West 

GSFC 



Edward Lowe 

GSFC 

Eugene Nelson 

KSC 





Axel Roth 

MSFC 

Rick Nelson 

DoD/USAF 





William C. Webb 

GSFC 

Raymond L. Norman, Jr. KSC 





R. B. (Pete) Williams 

JSC 

Christian Poulsen 

KSC 







Kal S. Purushotham 

MSFC 







Haley Rushing 

KSC 







David H. Suddeth 

GSFC 







Libby Wells 

KSC 







Lynn Wolard 

DoD/USAF 






* leader 
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PANEL MEMBERSHIP 


’UMiNliULk) 


ASSOCIATE MEMBERS 


PANEL 1 

Space Operations 
ana Support Systems 

PANEL 2 

Ground Operations 
and Support Systems 

PANEL 3 

User Development 
and Integration 

PANEL 4 
Management 
Integration 

Kathleen Abotteen 

JSC 

Steve Alexander 

LeRC 

Harry Atkins MSFC 

Katherine R. Daues 

JSC 

Bob Brotherton 

GSFC 

Richard Baldwin 

GSFC 

Susan (Stacy) Edgington HQ/I 

Donald Eide 

HQ/SO 

Jack Bullman 

MSFC 

Charles Baugher 

MSFC 

Walt Feitshans KSC 

Paul Heartquist DoD/USAF 1 

Rick Chappell 

MSFC 

Stanley Blackmer 

JSC 

F. Michael Goeser HQ/MC 

Harold Miller 

HQ/SO 

Tony Comberiate 

GSFC 

Lloyd Chamberlin 

KSC 

Ben Higbie DoD/USAF 

James Robinson 

HQ/SO 

Denis Dahms 

JSC 

Robert R. Corban 

LeRC 

Bryant J. Keith HQ-M 

Robert J. Soltess 

HQ-S 

Charles Elachi 

JPL 

William Galoway 

MSFC 

Richard Ott HQ-M 

Mike Stevens 

HQ/T 

Jerome B. Hammack 

JSC 

Guy Gardner 

JSC 

Thomas Overton KSC 

Guilio Varsi 

HQ/S 

Adrian Hooke 

JPL 

Charles E. Howard 

JSC 

Lowell Primm HQ/MC 



Bill Kilpatrick 

MSFC 

Gary Johnson 

MSFC 

Donna A. Shortz HQ/S 



Kristan Lattu 

JPL 

Gerald P. Kenney 

JSC 

John R. Yadvish HQ/I 



Roy C. Lester 

MSFC 

Harold A. Loden 

JSC 




Daryl Rasmussen 

ARC 

Joe L. Lusk 

MSFC 




Jack Schwartz 

JPL 

James F. McGuire 

HQ/S 




Taylor Wang 

JPL 

Herman Mobley 

JSC 




Jerry Weiler 

MSFC 

Gregory A. Opresko 

KSC 




Bob Williams 

JSC 

William H. Oyler 

KSC 




Michael Wortham DoD/USAF 

Glenn R. Parker 

KSC 






David Tipton 

KSC 






Dennis Vender Tuig 

GSFC 






Emeterio Zarraonandia 

KSC 





PANEL MEMBERSHIP 
(Continued] 
MEMBERS AT LARGE 


James F. Buchli 

JSC 

Philip Cressy 

GSFC 

Michael Devirian 

HQ-E 

Kenneth Frost 

GSFC 

Ronald H. Gerlach 

JSC 

Adam Gruen 

HQ-LBH 

David C. Leestma 

JSC 

Michael C. McEwen 

JSC 

Remer Prince 

HQ-SU 

Erwin Schmerling 

HQ-E 

Ray Sizemore 

LeRC 

Marsha Torr 

MSFC 
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SPACE STATION OPERATIONS TASK FORCE SPECIAL CONSULTANTS 


NAME 

ORGANIZATION 

PANEL NO 

Joe Allen 

Space Industries Inc. 

3 

Herbert Bartlett 

Aeroflex 

2 

William E. Brooks 

Booz, Allen and Hamilton 

4 

Kandy Davis 

U of Colorado 

1 

John Egan 

The Egan Group 

3 

Robert T. Everline 

Consultant 

3 

Dennis Fielder 

TADCORPS 

4 

Owen Garriot 

Consultant 

1 

David Greulich 

Cabot Corp 

3 

John Hunsucker 

University of Houston 

4 

James T. Kaidy 

Booz, Allen and Hamilton 

4 

Bill Lenoir 

Booz, Allen and Hamilton 

4 

Bryon Lichtenberg 

PSI 

1 

James Moore 

Consultant 

2 

Henry J. Pierce 

Booz, Allen and Hamilton 

4 

Chris Podsiadly 

3M Company 

3 

Mark Oderman 

CSP Associates, Inc. 

4 

George Schmidt 

Booz, Allen and Hamilton 

4 

Rebecca Simmons 

CSP Associates, Inc. 

4 

Ed Sofinowski 

Consultant 

1 

Marc Vaucher 

CSP Associates, Inc. 

4 

Charles Walker 

McDonnell Douglas Astronautics Co. 

3 

Charles Williams 

Earth Observation Satellite Co. 

3 

Michael Wiskerchen, Jr. 

Stanford University 

3 

Donald York 

University of Chicago 

3 


SOME OTHER CONTACTS 

• Center Directors 

• Other Associate Administrators 

• Past Program Directors 

- Charles Mathews 

- William Schneider 

- Leland Belew 

• Projects/Programs 

- SR 71 

- Trident Submarine 

- British Navy Submarine Operations 
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BACKGROUND BRIEFINGS COMPLETED 


• SSOTF Special Directions A. Stofan 

• What is a Space Station T. Finn 

• Background and Status of Agreements with Internationals G. Rice/M. J. Smith 

• Space Station Baseline Configuration T. Bonner 

• Space Station Evolution Configuration D. Black 

• Development Program Management J. Aaron 

• Space Station Budget Perspectives J. Sheahan/D. Bates 

• Columbia Lakes Operations Symposium Review C. Mathews 

• Integration Assembly and Checkout H. Benson 

• Characteristics of R&D vs. Operations Organization J. Hunsucker 

• Pricing Policy Overview J. Smith 

• Space Station Information Systems (SSIS) D. Hall 

• Technical and Management Information Systems (TMIS) C. Harlan 

• KSC Operations Lessons Learned J. Ragusa 

• Congressional Perspectives M. D. Kerwin 

• SS Work Breakdown Structure W. Whittington 

• Commercial Operations Coopers-Lybrand/J. Egan 

• Space Policy CSP/M. Vaucher 

• Soviet Space Station DoD and B. J. Bluth 

• Program Logic W. Whittington 

• Automation and Robotics G. Varsi 

• Astrophysics F. Martin 

• Lessons Learned From Other Programs Skylab, Spacelab, et al. 
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ABEX CORPORATION 
AEROJET TECH SYSTEMS CO. 

AIR PRODUCTS & CHEMICALS INC. 

ALCOA TECHNICAL CENTER 
ALLIS CHALMERS CORPORATION 
AMERICAN CYANAMID 
ARMCO, INC. 

ASARCO, INC. 

ASHLAND CHEMICAL COMPANY 
ATLANTIC RICHFIELD CO. - ARCO 
AT&T BELL LABORATORIES 
BALL AEROSPACE SYSTEMS DIVISION 
BECTON-DICKINSON COMPANY 
BELL COMMUNICATIONS RESEARCH 
BOEING 

BORG-WARNER CORPORATION 
BOOZ, ALLEN AND HAMILTON 
BRUNSWICK CORPORATION 
CACI 

CAMUS, INC. 

CSP ASSOCIATES, INC. 

COMPUTER SCIENCES CORPORATION 
COMBUSTION ENGINEERING INC. 

COMARCO 

COMSIS 

CORNING GLASS WORKS 
CUMMINS ENGINE COMPANY 
LOCKHEED MISSILE & SPACE COMPANY 
LTV-VOUGHT CO. 

MARTIN MARIETTA 
MECHANICAL TECHNOLOGY, INC. 

McDonnell douglas 
McDonnell douglas technical 
SERVICES CO. 

NASA SOUTHERN TECHNOLOGY APPLICATION 
CENTER (STAC) 

NORTON COMPANY 
OAO CORPORATION 

OWENS - CORNING FIBERGLASS CORPORATION 
PACE AND WAITE, INC. 

PERKIN-ELMER 
PHILLIPS PETROLEUM 
PRIME WELDING SYSTEMS 
P.R. MILLER ASSOCIATES 
RCA 

REMOTE MANIPULATOR SYSTEMS DIVISION 

ROCKETDYNE 

ROCKET RESEARCH CO. 

ROCKWELL INTERNATIONAL 
SCHERING-PLOUGH CORPORATION 
SPACE COMMUNICATIONS CO. 

SPAR AEROSPACE 
SPERRY FLIGHT SYSTEMS 


DARTCO 

EAGLE ENGINEERING 
ESSEX CORPORATION 

EXXON RESEARCH & ENGINEERING COMPANY 
FAIRCHILD REPUBLIC CO. 

FLEXWATT CORP. 

FORD AEROSPACE & COMMUNICATIONS 
CORPORATION 
GARRETT CORPORATION 
GARRETT FLUID SYSTEMS COMPANY 
GARRETT PNEUMATIC SYSTEMS DIVISION 
GENERAL DYNAMICS-SPACE SYSTEMS DIV. 
GENERAL ELECTRIC 
GRUMMAN 
HARRIS CORPORATION 
HERCULES, INC. 

HONEYWELL INC. 

HUGHES AIRCRAFT CO. 

IBM 

INTEL CORPORATION 
INTEGRATED SYSTEMS ANALYSIS, INC. 
INTERMETRICS INCORPORATED 
J.M. HUBER COMPANY 
KAMAN SCIENCES CORP. 

LIFE SYSTEMS, INC. 


STARK & STROBEL ASSOCIATES 
STAR TECHNOLOGY AND SCIENCE 
SUNDSTRAND MISSILE & SPACE POWERS 
SYSTEMS 

TELEDYNE BROWN ENGINEERING 
TELEPHONICS CORPORATION 
TEXACO, INC. 

THERMACORE, INC. 

THUR ENGINEERING AND MANAGEMENT, INC. 
TRW SPACE AND TECHNOLOGY GROUP 
UMPQUA RESEARCH CO. 

UNION CARBIDE CORPORATION 
UNITED AIRLINES 

UNITED STATES GYPSUM COMPANY 
UNITED TECHNOLOGIES CORP. 

UNITED TECHNOLOGIES POWER SYSTEMS (UTC) 

VITRO CORPORATION 

WESTINGHOUSE ELECTRIC 

WHIRLPOOL CORPORATION 

WYLE LABORATORIES 

XEROX CORPORATION 


Bold means Briefed Task Force 
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APPENDIX B 


KEY OPERATIONS FUNCTIONS 

The SSOTF Recommended (operations) Framework was developed using the following basic approach: 

• Development of a functional description of the operations job (the "what”). 

• Development of a description and illustration of the Recommended Framework (the "how") along with a 
discussion of key options considered. 

• Development of a description and illustration of the recommended mature operations organization 
performing the functions within the context of the Recommended Framework. 

The purpose of this Appendix is to elaborate upon the operations functions developed by the SSOTF. These 
functions establish the basis for discussion of the Recommended Framework in various areas of operations. 

1. FUNCTIONAL CATEGORIES 

Viewed top-down, the jobs to be performed for planning and conducting operations on the manned base and 
the platforms fall naturally into three basic categories: Program Policies, those activities managed by the Space 
Station Program which affect both Station and user operations; User Operations, those activities for which the 
user community is responsible; and Space Station Program Operations, those activities for which the 
International organizations supporting the Space Station are responsible. Exhibit 1 illustrates these categories. 

The summary categories illustrated in Exhibit 1 reflect a much more detailed functional analysis performed by 
the SSOTF. The brief sections below provide an overview of this process and illustrate in more detail the 
functional areas defined and analyzed by the SSOTF in developing the Recommended Framework. 



• USER/SYSTEM INTEGRATION PLANNING 


• USER ACCOMMODATION SERVICES 


• USER OPERATIONS SUPPORT 


SUSTAINING ENGINEERING AND 
CONFIGURATION CONTROL 


• TRANSPORTATION SERVICES PLANNING 

• LOGISTICS SUPPORT PLANNING 


• PRE/POST FLIGHT OPERATIONS 

♦ INTEGRATED LOGISTICS SUPPORT 


• INFORMATION SYSTEMS SUSTAINING 
ENGINEERING AND CONFIGURATION 
CONTROL 


• DATA SYSTEMS SERVICES PLANNING 


• INFORMATION SYSTEM OPERATIONS 

• OPERATIONS SUPPORT FACILITIES 
SUSTAINING ENGINEERING (MAO) 

• CONFIGURATION CONTROL OF 
OPERATIONS PLANS, PROCEDURES, AND 
DATA 


• DATA SYSTEMS INTERFACE SUSTAINING 
ENGINEERING AND CONFIGURATION 
CONTROL 

• SPACE SYSTEMS AND PAYLOAD 
INTERFACE SYSTEMS SUSTAINING 
ENGINEERING AND CONFIGURATION 
CONTROL 


• OPERATOR TRAINING 


EXHIBIT ! OPERATIONS FUNCTIONS 
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2. FUNCTIONAL HIERARCHY 


The process of developing alternative operations frameworks for the manned Space Station and the Platforms 
began with defining the top-level operations activities in functional terms. Exhibit 2 illustrates the top-level 
functional flow at three levels; Program Policy, Program Integration, and Program Execution : 



EXHIBIT-2 SPACE STATION PROGRAM 
HIERARCHY OF OPERATIONS FUNCTIONS 


SPACE STATION OPERATIONS MANAGEMENT FUNCTIONS 

• PROGRAM POLICY - Those functions concerned primarily with establishing and coordinating the objectives 
and policies of the organization. These objectives and policies affect a broad range of users and 
institutional activities. 

• PROGRAM INTEGRATION - Those functions concerned primarily with using the established objectives and 
policies to produce plans and directions for accomplishing stated objectives and policies. While affecting a 
broad range of users and institutional activities, they become progressively more detailed and focus on 
managing and controlling operations planning and resource utilization. 

• PROGRAM EXECUTION - Those functions whose products and activities result in either an institutional end 
product; or, products and activities accomplishing the details of a plan in support of a specific end product. 

Within each of these three areas, the Task Force took a "top-down" approach to defining the operations job 

for the Space Station Program. The complete list of top-level operations functions developed by the Space 

Station Operations Task Force is illustrated in Exhibit 3. 
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PROGRAM POLICY FUNCTIONS 


PROGRAM INTEGRATION FUNCTIONS 


PROGRAM EXECUTION FUNCTIONS 


1 . SPACE STATION PROGRAM OPERATIONS 
OBJECTIVES & POLICY FORMULATION 

2. STRATEGIC UTILIZATION & OPERATIONS 
PLANNING 

3. INTERNATIONAL NEGOTIATIONS 

4. EVOLUTION PLANNING 

5. SAFETY, RELIABILITY/ MAINTAINABILITY & 
QUALITY ASSURANCE 

6. BUDGET PANNING & CONTROL 

7. TRANSPORTATION SERVICES PANNING 

8. MARKETING & USER ANALYSIS 


1. INTEGRATED OPERATIONS PANNING 
(SEPARATE FOR MANNED BASE AND 
PATFORMS EXCEPT FOR COP SERVICING) 

IA. TACTICAL OPERATIONS PANNING 
(MANNED BASE & PATFORMS) 

IB. MANNED BASE INCREMENT PANNING 
(INCLUDES COP SERVICING) 

2. USER INTEGRATION & ACCOMMODATION 
SERVICES 

3. MANNED BASE & SUPPORT SYSTEM 
ENGINEERING & INTEGRATION 

4 PATFORM & SUPPORT SYSTEMS 
ENGINEERING & INTEGRATION 

5. INFORMATION & NETWORK SYSTEMS 
ENGINEERING & INTEGRATION 

6. SAFETY, RELIABILITY/MAINTAINABILITY & 
QUALITY ASSURANCE 

7. BUDGET ADMINISTRATION & COST 
CONTROL 

8. INTEGRATED LOGISTICS SYSTEMS 

9. CONFIGURATION CONTROL (SPACE 
SYSTEMS, INTERFACING GROUND SYSTEMS, 
PAYLOAD INTERFACES, AND PROGRAM 
INTEGRATION-LEVEL OPERATIONS PANS) 


1. MANNED BASE SYSTEM OPERATIONS 

2. MANNED BASE USER OPERATIONS SUPPORT 

3. PATFORM(S) SYSTEM OPERATIONS 

4. PATFORM USER OPERATIONS SUPPORT 

5. PREFLIGHT/POSTFLIGHT OPERATIONS 

6. INTEGRATED LOGISTICS OPERATIONS 

7 . INFORMATION SYSTEM OPERATIONS 

8. SUSTAINING ENGINEERING 

8A. SPACE SYSTEMS 
8B. GROUND SYSTEMS 
8C. PAYLOAD INTERFACE ENGINEERING & 
INTEGRATION 

9. CONFIGURATION MANAGEMENT 

9A. SPACE SYSTEMS 
9B. GROUND SYSTEMS 
9C. PAYLOAD INTERFACES 
9D. EXECUTION-LEVEL OPERATIONS PANS 
& PROCEDURES (INCLUDING CONTROL) 

10. SAFETY, RELIABILITY/MAINTAINABILITY & 
QUALITY ASSURANCE 

11 OPERATOR TRAINING (CREW & GROUND 
PERSONNEL) 


EXHIBIT-3 SPACE STATION PROGRAM KEY OPERATIONS FUNCTIONS 


3. CRITERIA FOR DEVELOPING THE OPERATIONS FUNCTIONS 

There were several important criteria applied during the process of defining the "what" of the operations job. 

These were: 

• The functions were limited to those directly related to operations. Institutional functions of the Partners 
and their various centers were assumed to be in place and providing required support in areas such as 
facilities, personnel, and finance. 

• The operations functions describe the end-to-end operations job without regard to "who" performed the 
job or "where" the job would be performed. 

• The initial functional definitions recognized the differences in the operations of the manned based and the 
unmanned/man-tended platforms and listed separate functional areas at the Program Integration and 
Program Execution levels. This is particularly true for the polar orbiting platforms which operate 
independently of the manned base and co-orbiting platforms in all operational phases. 

• A great deal of emphasis was placed on the concept of "value-added" in defining functions. In general, if 
the products of a functional area did not add value to the next lower level in the hierarchy, the function was 
either deleted or redefined. 

• Functions were defined in such a way as to promote delegation of authority and responsibility to the lowest 
possible level and with clear, simple lines ot communication to other functional areas. 

• For completeness, the operations functions include functions performed by organizations other than 
NASA's Office of Space Station or the offices of the International Partners responsible for Space Station 
Program activities. Examples include communications and tracking services provided by Partner 
organizations and NASA's Office of Spaceflight Tracking and Data Systems, safety and quality assurance 
provided by NASA's Office of Safety, Reliability, Maintainability, and Quality Assurance, and space 
transportation services provided by NASA's Office of Spaceflight. 

4. FUNCTIONAL AREA PRODUCTS AND END-TO-END FUNCTIONAL PRODUCT FLOW. 

The top-level functions illustrated in Exhibit 3 were further developed to illustrate specific activities, products, 

and interfaces to other functional areas. The results are displayed in Exhibit 4. 
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STRATEGIC UTILIZATION & 



OPERATIONS PLANNING: 



MULTILATERAL CONTROL BOARD 



P2-C 



1 . RESOURCE ALLOCATION FOR STATION OPS, G&E (P2-A) 

2. PARTNER RESOURCE ALLOCATION (P2-B) 

3. APPROVED INTERNATIONAL USER LIST (P2-B) 

4. GROWTH PLANS (P2-A) 

5. PROCURED TRANSPORTATION SLOTS (P7) 


1. APPROVED CONSOLIDATED UTILIZATION PLAN (II -A) 

- 5 YEAR STATION RESOURCE ALLOCATION 

- SELECTED USERS WITH YEAR AND PRIORITY ASSIGNMENTS 

- MAJOR STATION CAPABILITY ENHANCEMENT PLANS 

- 5 YEAR NSTS/ELV TRANSPORTATION PLAN (W/VEHICLES 
& APPROX. LAUNCH DATES) 

2. USER RESOURCE ALLOCATION BY YEAR (P9) 


1 . Analysis of user requirements, partner resource allocations, and approved users in consideration of 5 year projected Station resource 
availabilities and core resource requirements. The overall objective in the decision process is to dedicate the maximum level of resources over the 
long term to the accomplishment of payload activity while at the same time providing adequate allowance for maintenance of Station systems and 
enhancement of payload accomodation ability, (t.1.4) 

2. Finalization of overall allocation of resources to users vs. Station core activities (maintenance, growth, testing, etc.) on a year-by-year basis. 

( 1 . 1 ) 

3. Finalization of list of international users on a yearly basis. (5.5.2) 

4. Final approval of resource division between international users. (5.5) 

5. Prioritization of users and payloads; Scheduling done on a yearly basis. (5.5.2) 

6. Review and final approval of plans for Station enhancement put forth by the Evolution Planning function, negotiated and approved by the Systems 
Operations Panel. 

7. Approval of transportation capability procured by Transportation Services, and incorporation into the Consolidated Utilization Plan. 


EXHIBIT 4 - SPACE STATION PROGRAM POLICY FUNCTIONS AND PRODUCTS 


I 


In Exhibit 4, inputs are provided in the form of products or information from other functional areas. In addition 
to the name of the input product, the source code is provided in parentheses. For example, input item 1 
"Resource Allocation for Station Operations (P2-A), is a product from the Strategic Utilization and Operations 
Planning, Systems Operations Panel function. The specific activities occurring in each function are defined at 
the bottom of the chart. These definitions were developed by the SSOTF using existing Program 
documentation ("Space Station Operations Functions" dated 10/15/86 and JSC 30000) as reference sources. The 
numbers in parentheses following a definition (e.g., 1.1.4 in item 1) refer to paragraphs in the "Space Station 
Operations Functions" document. Additional definitions were prepared by the SSOTF to completely describe 
all activities necessary to develop the output products for each functional area. 

As noted earlier, emphasis was placed on "value-addded" products and clear lines of communications among 
functional areas. A complete listing of these detailed functional definitions with their associated products 
follow. 
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SPACE STATION 

PROGRAM POLICY FUNCTIONS AND PRODUCTS 



SPACE STATION PROGRAM 



OPERATIONS OBJECTIVES & 



POLICY FORMATION 



PI 



1. NATIONALLY ORIENTED AND INTEGRATED UTILIZATION 
REQURENENTS 

2. MOU's (P3) 

3. POLITICAL INPUTS 

- NATIONAL GOALS 

- PROJECTED BUDGETS 

4. INTERNATIONAL DEVELOPMENT AND OPERATIONS SCHEDULES 
<P3) 

5. FUTURE BUDGET REQUIREMENTS (P6) 

6. FUNDING ALLOCATIONS (EXTERNAL) 


1. SCHEDULE GOALS (P2) 

2. CAPABILITY GOALS (P2) 

3. TRANSPORTATION POLICY <P7) 

4. BUDGET GOALS (P6) 

5. MARKETING POLICY (P8) 

6. ROLES, RESPONSIBILITIES AND GUIDELINES 

7. NATIONAL GOALS 

8. SR/M&QA POLICY (PS) 

9. FUNDING REQUESTS (EXTERNAL) 

10. COST, RISK ASSESSMENTS 


1. Overall program management function. Ultimately responsible for all policy-level products and the overall management and control of the Space 
Station Program. 

2. Analysis of internal and external environment. 

3. Goals and objectives formulation (generally in terms of program capabilities and desired resource allocation and utilization policies). (1.1) 

4. Strategies to achieve objectives. Key items include changes in capabilities, technology development and incorporation, marketing policies, 
pricing policies, and transportation and logistics policies. (1.1. 1,1. 1.3) 

5. Develops policies for recovering appropriate Space Station operating costs from users. (1.1.3) 

6. Sponsors -advisory groups in support of user requirements definition, user prioritization, and user input to station system requirements, designs, 
and operational approaches. (1.5.4) 

7. Submit requests to non-NASA government agencies in charge of overall Space Station Program funding. 

8. Performance of cost and risk assessments, and other studies to assist in the formulation of Program goals, priorities, and direction. 


SPACE STATION 

PROGRAM POLICY FUNCTIONS AND PRODUCTS 


STRATEGIC UTILIZATION & 
OPERATIONS PLANNING: 
SYSTEM OPS PANEL 
P2-A 




1. MOU's (P3) 

2. SCHEDULE GOALS (PI) 

3. GROWTH PUNS (P4) 

4. GROWTH & EVOLUTION TRANSPORTATION REQUIREMENTS (P4) 

5. PROCURED TRANSPORTATION SLOTS (P7) 

6. 5 YEAR TOTAL STATION RESOURCE AVAILABILITY (I1-A.3) 

7. 5 YEAR OVERHEAD RESOURCE REQUIREMENTS (II -A.3) 

8. 5 YEAR DESffCD MARGINAL RESOURCE REQUIREMENTS FOR 
TESTING, MAJOR MAINTENANCE, ETC. (I1-A.3) 

9. 5 YEAR TRANSPORTATION REQUIREMENTS FOR STATION OPS 
8 MAINTENANCE (I1-A.3) 


1 . ALLOCATION OF RESOURCES FOR STATION CORE OPERATIONS 
(P2-C) 

2. ALLOCATION OF RESOURCES FOR STATION GROWTH AND 
EVOLUTION (P2-C) 

3. 5 YEAR TRANSPORTATION REQUIREMENTS FOR STATION OPS 
AND GROWTH (P7) 

4. DATA SYSTEMS & UTILIZATION POLICIES FOR STATION USE 
(15) 


1. Responsible, in conjunction with the User Operations Panel, for implementing Memoranda of Understanding (MOU’s) between the partner nations 
with respect to the Space Station resources and their allocation between Station operations and the user community. (1.1.4) 

2. Consolidation of transport requirements for Station operations, maintenance and growth, for submission to the Transportation Services function. 

3. Allocation of non-optional Station resource requirements needed for proper functioning of the Station. (1.1.4) 

4. Through negotiation with User Ops Panel, 5 year resource allocations made for Station core operations (day-to-day operation, major 
maintenance, repair, testing, etc.). (1.1.4) 

5. Negotiation for 5 year schedule of Station enhancements, growth and evolution. 

6. Formulation of policies and long range plans concerning data system utilization for Station operations. 
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SPACE STATION 

PROGRAM POLICY FUNCTIONS AND PRODUCTS 



STRATEGIC UTILIZATION & 



OPERATIONS PLANNING: 



INTERNATIONAL USER OPS PANEL 



P2-B 



1. MOU's (P3) 

2. USER RESOURCE REQUESTS (P9) 

3. NATIONALLY SELECTED USERS (P9) 

4. GROWTH PLANS (PA) 

5. PROCURED TRANSPORTATION SLOTS (P7) 

6. 5 YEAR TRANSPORTATION REQUIREMENTS FOR SELECTED 
USER SUPPORT (I1-A.1) 

7. TRANSPORTATION REQUIREMENTS FOR POTENTIAL USERS 

(P9) 


1 . PARTNER RESOURCE ALLOCATIONS (P2-C) 

2. APPROVED INTERNATIONAL USER LIST (P2-C) 

3. 5 YEAR TRANSPORTATION REQUIREMENTS FOR USER SUPPORT 
<P7) 

4. DATA SYSTEMS & UTILIZATION POLICIES FOR USER SUPPORT 
(15) 


1. Responsible for implementing bilateral Memoranda of Understanding (MOU*6) pertaining to the division of user-designated resources between user 
boards of the different partner nations. (1.1) 

2. Analysis of user resource requests with respect to budget allocations, transportation considerations, and MOU's for evaluation and approval of 
selected payload lists from user boards. (1.1.4) 

3. Overall guidelines are formulated as to the division of resources among partners, and to general priorities in resource allocation. (1.1.4) 

4. Consolidation of transportation requirements for selected users (in C.U.P.) and potential users (from User Boards) for submission of overall 5 
year user transportation requirements to the Transportation Services function. 

5. Formulation of policies and long-range plans concerning data system utilization for support of Station users. 


SPACE STATION 

PROGRAM POLICY FUNCTIONS AND PRODUCTS 



STRATEGIC UTILIZATION & 



OPERATIONS PLANNING: 



MULTILATERAL CONTROL BOARD 



P2-C 



1. RESOURCE ALLOCATION FOR STATION OPS, G4E (P2-A) 

2. PARTNER RESOURCE ALLOCATION (P2-B) 

3. APPROVED INTERNATIONAL USER LIST (P2-B) 

4. GROWTH PLANS (P2-A) 

5. PROCURED TRANSPORTATION SLOTS (P7) 


1 . APPROVED CONSOLIDATED UTILIZATION PLAN (II -A) 

- 5 YEAR STATION RESOURCE ALLOCATION 

- SELECTED USERS WITH YEAR AND PRIORITY ASSIGNMENTS 

- MAJOR STATION CAPABILITY ENHANCEMENT PLANS 

- 5 YEAR NSTS/ELV TRANSPORTATION PUN (W/VEHICLES 
& APPROX. UUNCH DATES) 

2. USER RESOURCE ALLOCATION BY YEAR (P9) 


1. Analysis of user requirements, partner resource allocations, and approved users in consideration of 5 year projected Station resource 
availabilities and core resource requirements. The overall objective in the decision process is to dedicate the maximum level of resources over the 
long term to the accomplishment of payload activity while at the same time providing adequate allowance for maintenance of Station systems and 
enhancement of payload accomodation ability. (1.1.4) 

2. Finalization of overall allocation of resources to users vs. Station core activities (maintenance, growth, testing, etc.) on a year-by-year basis. 
( 1 . 1 ) 

3. Finalization of list of international users on a yearly basis. (5.5.2) 

4. Final approval of resource division between international users. (5.5) 

5. Prioritization of users and payloads; Scheduling done on a yearly basis. (5.5.2) 

6. Review and final approval of plans for Station enhancement put forth by the Evolution Planning function, negotiated and approved by the Systems 
Operations Panel. 

7. Approval of transportation capability procured by Transportation Sen/ices, and incorporation into the Consolidated Utilization Plan. 
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SPACE STATION 

PROGRAM POLICY FUNCTIONS & PRODUCTS 


INTERNATIONAL 

NEGOTIATIONS 

P3 


I. USER REQUIREMENTS 
Z NATIONAL GOALS (PI) 

3. STATION SYSTEM CAPABILITIES 

4. CONFIGURATION, GROWTH & EVOLUTION PLANS (P4) 

5. SCHEDULES (PI) 

6. SR/M&QA POLICY (P5) 

7. BUDGET GOALS (P6) 

8. PRICING POLICY (P6) 

9. ROLES AND RESPONSIBILITIES (PI ) 

10. TRANSPORTATION POLICY (P7) 

II. INTERNATIONAL CREW UTILIUZATION POLICY (Pi) 


1. MOU’s (P2) 

2. FUNDING REQUIREMENTS (P2) 

3. DEVELOPMENT AND OPERATIONS SCHEDULES (P2) 

4. PARTNER COMMITMENTS (P2) 


1. Develop bilateral Memoranda of Understanding (MOU) between the United States and the international partners of the Space Station Program. 
These MOU*s describe funding levels, responsibilities for space and ground segment development, operations, management concepts, development and 
operations schedules. (5.5.1 ,5.5.3) 

2. Support for the analysis and development required for negotiation of agreements with international partners. (5.5.1) 

3. Provide operational evaluation of domestic and international roles and missions. (5.5.2) 

4. Analyze domestic and international functional interfaces to ensure clear authority and procedural protocol. (5.5.3) 

5. Negotiate roles and responsibilities with international partners. (5.5.1) 


SPACE STATION 

PROGRAM POLICY FUNCTIONS AND PRODUCTS 


EVOLUTION 

PLANNING 

P4 




1. SCHEDULE GOALS (PI) 

2. CAPABILITY GOALS (PI) 

3. BUDGET GOALS/PRQJECTIONS (PI) 

4. SR/M&QA POLICY (P5) 

5. CAPABILITY REQUIREMENTS (P2) 

6. 5-YEAR DEVELOPMENT BUDGETS (P2) 

7. 5-YEAR DEVELOPMENT SCHEDULES (P2) 

8. WTERNATIONAL DEVELOPMENT AND OPERATIONS SCHEDULES 
(P3) 

9. STATION, TRANSPORTATION, INSTITUTIONAL, INFORMATION 
SYSTEM CAPABILITIES 

10. PROJECTED REQUBEMENT S/MARKET RESEARCH RESULTS 
(P8) 

1 1 . SYSTEMS PERFORMANCE EVALUATIONS (P5) 

1Z GROWTH REQUIREMENTS (P8, 12) 


1. GROWTH PLANS, CONFIGURATIONS (P2, II) 

Z BUDGET REQUIREMENTS (P2) 

3. TECHNOLOGY REQUIREMENTS (P2) 

4. GROWTH AND EVOLUTION EVALUATION REQUESTS (E8-A) 

5. GROWTH & EVOLUTION TRANSPORTATION REQUIREMENTS 
(P2-A) 


1. Analysis of growth requirements, goals and policies, budget and technology limitations to formulate plans for station growth. 


2. Analysis of ail strategic plans and policies to determine the direction and extent of evolution. 


3. Determine design impacts, particularly hooks and scars on the current station configuration at any phase of the program, to allow for further 
evolution. 


4. Establish plans for the use of automation and robotics as an aid to operations. 

5. Set up performance assessment system to identify opportunities/requirements for automation and evolution paths. 

6. Perform life cycle cost studies to guide planning for effective evolution at the lowest possible cost to the Program. 

7. Manage Space Station system growth and evolution programs. 

6. Formulate transportation requirements for growth and evolution plans. 
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SPACE STATION 

PROGRAM POLICY FUNCTIONS & PRODUCTS 



SAFETY, RELIABILITY/ 



MAINTAINABILITY & QUALITY 



ASSURANCE 



P5 



1 . SR/M&QA POLICY (PI ) 1 . SAFETY REQUIREMENTS & DIRECTIVES 

2. G&E PLAN (P4) 2. SYSTEM MODIFICATION AND GROWTH AND EVOLUTION PLAN 

REVIEWS (P4) 


1. Program safety and quality assurance policy implementation and management of Integration and Execution level safety functions. 

2. Independent reviews, analyses, and reports on proposed system modification and growth and evolution plans. 


SPACE STATION 

PROGRAM POLICY FUNCTIONS & PRODUCTS 


* 


BUDGET PLANNING 
AND CONTROL 
P6 




1 . ACCOUNTING AND CONTROL GUIDELINES (17) 

2. AUDITS 

3. OPERATIONS BUDGETS (17) 

4. DEVELOPMENT BUDGETS (17) 

5. OPERATIONS BUDGET ANALYSES 

6. FUTURE BUDGET REQUIREMENTS (PI ) 


2. Submit budget. (5.1.7) 

3. Integrate, analyze, validate, revise budget. (5.1.7) 

4. Develop models to estimate costs. (5.1.7) 

5. Analyze resources available. (5.1.7) 

6. Defend and justify budget. (5.1.7) 

7. Develop revised execution plan. (5.1.7) 


1. OPERATIONS BUDGET GOALS (PI) 

2. DEVELOPMENT BUDGET GOALS (PI ) 

3. EXPENDITURE REPORTS/OPERATIONAL VARIANCES (17) 

4. FINANCIAL RESOURCE ALLOCATIONS (EXTERNAL) 


1. Identify financial objectives and issue guidelines. (5.1.7) 
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SPACE STATION 

PROGRAM POLICY FUNCTIONS AND PRODUCTS 


* 


TRANSPORTATION 
SERVICES PLANNING 
P7 




1. TRANSPORTATION BUDGETS (P6) 

2. NSTS/ELV SCHEDULES (P1 1) 

3. NSTS/ELV GROWTH, DEVELOPMENT, IMPROVEMENT 
PROSPECTS (P1 1) 

4. PROJECTED TRANSPORTATION COSTS (P1 1) 

5. NSTS/ELV TRANSPORTATION ALLOCATIONS (Pi 1) 

6. 5 YEAR TRANSPORTATION REQUIREMENTS FOR STATION 
OPERATIONS & GROWTH (P2-A) 

7. 5 YEAR TRANSPORTATION REQUIREMENTS FOR USER SUPPORT 
(P2-B) 


1 . 5 YEAR NSTS TRANSPORTATION SLOT ALLOCATIONS (P2) 

2. 5 YEAR ELV TRANSPORTATION SLOT ALLOCATIONS (P2) 

3. NSTS/ELV TRANSPORTATION REQUESTS (P1 1 ) 


1. Analysis of input factors, schedules, budget considerations, and improvement prospects for projecting long-term ground and transport capability 
and availability. 

2. Perform feasibility studies to assess the utility of development and improvement of existing transportation methods and ground systems. 

3. Formulation of goals for acquisition of future transportation capability based upon projections of transportation demand by users and Station 
operation and growth (with System Operations Panel). 

4. Procurement and arrangement of NSTS/ELV transportation services. 

5. Analysis of transportation requirements, availabilities, costs, to determine the optimal mix (NSTS vs. ELV) of transportation services. 


SPACE STATION 

PROGRAM POLICY FUNCTIONS & PRODUCTS 




MARKETING AND USER 
ANALYSIS 
P8 




1. MARKETING POLICY (PI) 

2. POTENTIAL USERS 

3. SELECTED USERS (P2) 

4. SAFETY STANDARDS (P5) 

5. BASELINE SYSTEM CAPABILITIES AND CONFIGURATION (19) 


1 . USER CONTRACTS & SERVICE AGREEMENTS (12) 

2. PROJECTED USER REQUIREMENTS (P9) 

3. MARKETING EFFORTS (TO POTENTIAL USERS) 


1. Prepare and execute a marketing plan. The objectives of the plan are to identify potential users or user groups. (1.1.1) 

2. Contract negotiations with selected users, service agreements. (5. 5.1, 1.1. 6) 

3. Perform user market research. (1.1.1) 

4. Provide support to user advocate groups in developing potential users. (1.5.4) 

5. Prepare and distribute marketing and technical brochures. Participate in user workshops, Space 
Station-sponsored symposia, etc. (1.1.1) 

6. Identify potential users for Station & platforms. (1.1.1) 
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SPACE STATION 

PROGRAM POLICY FUNCTIONS AND PRODUCTS 


NOTE: This Is not a 

Station organization 
function! 



NASDA P9-D 

I! 

ESA P9*B 


NASA STATION 
USER BOARD 
w P9-A 


1. NATIONALLY SELECTED USERS (P2-C) 

Z USER TOTAL YEARLY RESOURCE ALLOCATIONS (BY PARTNER 
NATION) (P2-C) 

3. CANDIDATE PAYLOADS (PI 0) 

4. RESULTS OF PAYLOAD FEASIBILITY ANALYSES (SYSTEMS AND 
OPERATIONS) (12) 


1. RESOURCE REQUESTS (P2-B) 

2. NATIONALLY SELECTED USERS (P2-B) 

3. PAYLOADS FOR FEASIBILITY ANALYSES (12) 

4. YEARLY USER CLASS RESOURCE ALLOCATIONS (PI 0) 

5. INTERNAL RESOURCE ALLOCATION POLICY (PI 0) 

6. TRANSPORTATION REQUIREMENTS FOR POTENTIAL USERS 
(P2-B) 


1. Provide estimates of Space Station resource requirements based on their projections of potential users. (1.1) 

2. Analysis of candidate payloads for technical suitability, compatibility with allocated resources, etc., for recommendation to Strategic Utilization 
Planning function. (1.1.4) 

3. Analysis of user class needs, their respective payload requirements and total resource allocations, for the purpose of division of nationally 
allocated resources among the various user classes on a yearly basis. (1.1.4) 

4. Implementation of Presidential Space Station Utilization Policy (in the case of the U.S. User Board) by the NASA Associate Administrator, who is 
the chairman of the board. (1.1) 


SPACE STATION 

PROGRAM POLICY FUNCTIONS AND PRODUCTS 


NOTE: This is not a 

Station organization 
function! 



1 . YEARLY USER CLASS RESOURCE ALLOCATIONS (P9) 1 . CANDIDATE PAYLOADS (P9) 

2. MARKETING RESEARCH AND ASSISTANCE (P8) 

3. RESULTS OF FEASIBILITY ANALYSES (12) 


1 . User classes select users, both government and commercial, on the basis of feasibility analyses and resources made available by user board. 
Domestic examples of user classes would be commercial corporations, as well as NASA Code E, I, and R. 
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NOTE: This is not a 

Station organization 
function! 


SPACE STATION 

PROGRAM POLICY FUNCTIONS AND PRODUCTS 


INST; SERVICE Plf-D 


INST. SERVICE Pi 1-C 


INST. SERVICE P11-B 


NSTS/ELV TRANSPORTATION j 
'ORGANIZATION 
PT1-A 


1 . TRANSPORTATION SERVICE REQUESTS (P7) 1 . TRANSPORTATION SERVICE SCHEDULES AND CAPABILITIES 

2 . OTHER INSTITUTIONAL SERVICE REQUESTS {II ) (P7) 

2. TRANSPORTATION SERVICE ALLOCATIONS (P7) 

3. OTHER SERVICE (GROUND, PAYLOAD HANDLING, ETC.) 
SCHEDULES AND CAPABILITIES (II) 

4. OTHER SERVICE (GROUND, PAYLOAD HANDLING, ETC.) 
ALLOCATIONS (II) 


1* Provide the Transportation Services and Ground Resource Planning functions with information regarding the kinds of services available, their 
capabilities, schedules and their availabilities. 

2. Reserve services (NSTS, ELV, ground, engineering, payload handling, etc.) for each increment, according to requests issued by the 
Transportation Services and Ground Resource Planning functions. 
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SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS AND PRODUCTS 


INTEGRATED OPS PLANNING: 
TACTICAL OPS PLANNING 
1 1 -A 




1. CONSOLIDATED UTILIZATION PLAN (P2-C): 

- 5 YEAR STATIONAJSER RESOURCE ALLOCATION 

- SELECTED USERS WITH YEAR AND PRIORITY ASSIGNMENTS 

- MAJOR STATION ENHANCEMENT PLANS 

- 5 YEAR NSTS/ELV TRANSPORTATION PLAN (W/VEHICLES 
& APPROX LAUNCH DATES) 

2. STATION SUPPORT PLAN (II -A.3) 

3. INCREMENT-BY-INCREMENT CORE REQUIREMENTS (I1-A.3) 

4. INCREMENT-BY-INCREMENT OPTIONAL REQUIREMENTS 
(I1-A.3) 

5. INCREMENT-BY-INCREMENT RESOURCES AVAILABLE (II -A.3) 

6. INCREMENT REQUIREMENT CHANGE REQUESTS (II -B) 

7. TACTICAL OPS CHANGE REQUESTS (II -B) 

8. INTEGRATED PLAN ENGINEERING ANALYSES (E8-C) 

9. MANIFESTED PAYLOAD TRANSPORTATION REQUIREMENTS 
(M-A.1) 

10. PAYLOAD SUPPORT PLAN (I1-A.1) 

11. LOGISTIC SUPPORT PLANS (18) 

12. GSE AND PROCESSING SUPPORT 


1. RESOURCES AVAILABLE FOR STATION SUPPORT (I1-A.3) 

2. RESOURCES AVAILABLE TO USERS BY INCREMENT (I1-A.1) 

3. GROUND SUPPORT REQUIREMENTS (I1-A.2) 

4. TACTICAL OPERATIONS PLAN (II -B): 

- PAYLOAD ELEMENTS FOR NEXT 16 INCREMENTS 

- STATION ELEMENTS FOR NEXT 16 INCREMENTS 

- STATION OPS REQUIREMENTS FOR NEXT 16 INCREMENTS 


1. Analysis of inc re ment-by- increment station core and optional requirements, resources available, increment change requests in order to make 
final resource allocations to User Support Planning function and Station Operations and Maintenance Planning function for the next 1 6 flight 
increments. 

2. Development of integrated ground support requirements for submission to Ground Resource Planning function. 

3. Analysis of transportation availability, transport requirements, payload-to-increment assignments (Payload Support Plan), Station 
activity-to-increment assignments (Station Support Plan), increment change requests. Commission integrated plan engineering analyses performed 
by sustaining engineering support. 

4. Development and publication of the Tactical Operations Plan (TOP), describing the payload elements, Station elements, and Station operations 
requirements for each of the next 16 flight increments. 

5. Development of specific objectives for each flight increment. 

6. Final approval of the TOP by the Program Operations Control Board (POCB). 

7. Overall Station, platform, and supporting ground systems management. Responsible for ensuring compliance with established policies. 
Responsible for all tactical and execution level products and activities. (5.1.10) 

8. Controls and documents the baseline system configuration and capabilities. Documentation includes the Program Definition and Requirements 
Document (PDRD), Architecture Control Document (ACD), and Baseline Control Document (BCD). 

9. Management of key operations facilities. (5.2.1) Develops and tracks construction of facilities requirements through the approval cycle. (5.2.3) 
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SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS AND PRODUCTS 


* 


TACTICAL OPS PLANNING: 
USER SUPPORT PLANNING 
I1-A.1 




1. INCREMENT-BY-INCREMENT STATION RESOURCE 
ALLOCATIONS TO USER COMMUNITY (II -A) 

2. NEW USER SUPPORT REQUIREMENTS (12) 

3. PAYLOAD-TO-INCREMENT ASSIGNMENT SUPPORT (11 0) 

4. RESULTS OF USER-TO-INCREMENT FEASIBILITY AND 
COMPATIBILITY ANALYSES (12) 

5. CURRENT PAYLOAD STATUS (E2) 

6. FUTURE INCREMENT SUPPORT REQUIREMENTS (E2) 


1 . MANIFESTED PAYLOAD TRANSPORT REQUIREMENTS (II -A) 

2. PAYLOAD SUPPORT PUN (11- A) 

3. 5 YEAR TRANSPORTATION REQUIREMENTS FOR SELECTED 
USER SUPPORT (P2-B) 


1. Assignment of payloads to flight increments after considering payload priorities, incremental resources, feasibility and compatibility studies, in 
the Payload Support Plan. Overall objective is to obtain the most efficient matching of payload requirements and Station available resources, while 
maintaining payload priorities to the extent possible. (1.2) 

2. Analysis of new payload support requirements, feasibility and compatibility analyses, and future increment support requirements in consideration 
of Station resources available per increment. (1.2.1) 

3. Development of transportation requirements for currently and newly manifested payloads. (1.2.3) 

4. Commission feasibility and compatibility studies of new payloads for a given flight increment. (1.3.1) 

5. Formulate long-term transportation requirements for support of users listed in Consolidated Utilization Plan, for submission to Strategic 
Planning. 


SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS AND PRODUCTS 


* 


TACTICAL OPS PLANNING: 
GROUND RESOURCE PLANNING 
I1-A.2 




1. 2 YEAR PREUUNCH/POSTLANDWG OPS REQUIREMENTS 
(II * A) 

2. PAYLOAD LOGISTICS SUPPORT REQUIREMENTS (E2) 

3. CONSUMABLES STATUS (El) 

4. MAINTENANCE STATUS (El) 

8. NON-TRANSPORTATION INSTITUTIONAL SERVICE 
ALLOCATIONS (PI 1-B,C,...) 


1 . NON-TRANSPORTATION INSTITUTIONAL SERVICE REQUESTS 
(PI 1-B,C,...) 

2. GSE AND PROCESSING SUPPORT CAPABILITIES (II -A) 

3. GSE AND PROCESSING SUPPORT PUNS (II -A) 


1. Analysis of current user payload logistics support requirements, Station real-time probiem/resolution impacts. 

2. Determination of ground support capability constraints. 

3. Maintain launch schedule information provided by transportation vendors. (5. 1.1, 5. 1.2) 

4. Procurement of additional NASA institutional services such as ground support, payload handling, etc., and assessment of such capabilities for use 
in tactical operations planning. 
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SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS AND PRODUCTS 



TACTICAL OPS PLANNING: 



STATION OPS AND 



MAINTENANCE PLANNING 



I1-A.3 



1. INCREMENT-BY-INCREMENT GORE REQUIREMENTS (II -A): 

- REQUIRED MAINTENANCE 

- P ROV IS IONS/CON S U MM ABLES 

- STATION CARGO 

- CREW SUPPORT TIME 

2. INCREMENT-BY-INCREMENT OPTIONAL REQUIREMENTS (II -A): 

- OPTIONAL MAINTENANCE 

- GROWTH AND EVOLUTION PLANS 

3. INCREMENT-BY-INCREMENT RESOURCES AVAILABLE (II): 

- CREW TIME 

- POWER/THERMAL 

- ATTACH POINTS 

- RACK SPACE 

4. STATION SUPPORT PLAN (II -A) 

5. 5 YEAR TRANSPORTATION REQUIREMENTS FOR STATION OPS 
& MAINTENANCE (P2-A) 

1. Analysis of required Station core support requirements in consideration of resources allocated for non-user support by the Consolidated 
Utilization Plan. Overall objective is to allocate resources needed for non-optional support on an increment-by-increment basis before considering 
the resources available for payloads and other non-essential activity. 

2. Development of optional Station support requirements (maintenance, growth and evolution) on an increment-by-increment basis from research 
performed in the Sustaining Engineering function. 

3. Consolidation of information from sustaining engineering and real-time Station management function as to crew, power/thermal, attach point, 
rack space resources available. 

4. Projection of available resources, optional and non-optional Station support requirements into the next 16 flight increments (approx. 2 years). 

5. Development of the Station support requirements for the Tactical Operations Plan. These requirements outline proposed Station 
activity-to-increment assignments for Station support, as a recommendation to the Integrated Operations Planning function, for final approval by the 
Program Operations Control Board (POCB). 

6. Formulation of long-term transportation requirements for Station operations and maintenance, for use in Strategic Utilization Planning. 


1 . RESOURCES AVAILABLE FOR STATION SUPPORT ON AN 
INCREMENT-BY-INCREMENT BASIS (II -A) 

2. GROWTH AND EVOLUTION PLANS (P4) 

3. PERIODIC MAINTENANCE REQUIREMENTS (E8-A) 

4. CURRENT USER UPDATED REQUIREMENTS FOR STATION 
SYSTEMS SUPPORT (El) 

5. COMMON SYSTEM CAPABILITIES (El) 
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SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS AND PRODUCTS 


* 


MANNED BASE INCREMENT 
PLANNING: 

CRITICAL PATH SCHEDULING 
I1-B.1 




1. TACTICAL OPERATIONS PLAN (II -A): 

- PAYLOAD ASSIGNMENTS AND ALLOCATED RESOURCES 

- CREW NUMBER AND SKILL REQUIREMENTS 

- TRANSPORTATION SCHEDULES, VEHICLES, 
MASS/ELEMENT ASSIGNMENTS 

- STATION ACTIVITY REQUIREMENTS (MAINTENANCE, 
MODIFICATIONS GROWTH & EVOLUTION, TEST, C&O) 

- LOGISTICS ASSIGNMENTS AND UP/DOWN MANIFEST 

2. CURRENT INCREMENT RESOURCE AVAILABILITY INFORMATION 

(ED 


1 . TACTICAL OPERATIONS CHANGE REQUESTS (II -A) 

2. SPACE OPERATIONS MILESTONE SCHEDULE (I1-B.2) 

3. GROUND OPERATIONS MILESTONE SCHEDULE (I1-B.3) 

4. FLIGHT INCREMENT PLANS (El, E2) 


1. Analysis of transportation, maintenance, and payload schedules from Tactical Operations Plan. Identification of critical path, scheduling of 
critical events. 

2. Development of milestone schedules for space and ground operations. 

3. Responsibility for monitoring scheduled activities and making appropriate schedule modifications. 

4. Responsibility for insuring that tasks on critical path are accomplished according to schedule. 

5. Authority to redirect efforts of support functions in order to maintain schedule. 

6. Identification of problems with regard to scheduling in the Tactical Operations Plan, and submission of tactical operations change requests to the 
Integrated Operations Planning function. 

7. Selection and assignment of Increment Management Team. 

8. Planning of flight increment and transfer operation. 
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SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS AND PRODUCTS 



MANNED BASE INCREMENT 



PLANNING: 


' ■— - w 

SPACE OPERATIONS PLANNING 

W 


I1-B.2 



1. TACTICAL OPERATIONS PLAN (II -A): 

- PAYLOAD ASSIGNMENTS AND ALLOCATED RESOURCES 

- CREW NUMBER AND SKILL REQUIREMENTS 

- TRANSPORTATION SCHEDULES, VEHICLES, 
MASS/ELEMENT ASSIGNMENTS 

- STATION ACTIVITY REQUIREMENTS (MAINTENANCE, 
MODIFICATIONS GROWTH & EVOLUTION, TEST, C&O) 

- LOGISTICS ASSIGNMENTS AND UP/DOWN MANIFEST 

2. CURRENT INCREMENT RESOURCE AVAILABILITY INFORMATION 
(El) 

3. SPACE OPERATIONS MILESTONE SCHEDULE (II -B. 1 ) 

4. CREW, FLIGHT CONTROLLER TRAINING PLANS (Ell) 

5. REAL-TIME FACILITY SUPPORT (E5) 

6. STRUCTURAL, MASS, THERMAL ANALYSES (E8-A) 

7. CREW PROCEDURES SUPPORT 

8. PAYLOAD AND STATION LOGISTICS SUPPORT 
ANALYSES (18) 

9. ENGINEERING ANALYSES (E8-A) 


1. TACTICAL OPERATIONS CHANGE REQUESTS (II -A) 

2. INCREMENT EXECUTION PLAN (El ,E2) 

3. TRAINING REQUIREMENTS (Ell) 

4. FACILITIES REQUIREMENTS (E5) 

5. PAYLOAD AND STATION ENGINEERING DATA (E8-A) 

6. PROCEDURES REQUIREMENTS 

7. LOGISTICS REQUIREMENTS (18) 

8. FLIGHT PROCEDURE DOCUMENTATION REQUIREMENTS 

9. PAYLOAD TEST AND INTEGRATION PLANS (13,14) 

10. CREW, FLIGHT CONTROLLER TRAINING REQUIREMENTS (Ell) 


1. Analysis of resource availability, space operations milestone schedule, training plans, engineering and logistics analyses for development of 
space operations increment timeline, and for increment preparation. Increment execution plans will operate within the guidelines put forth in the 
Tactical Operations Plan. 

2. Development of crew and flight controller training requirements. (2.2.8) 

3. Development of real-time facilities requirements (data, voice, telemetry, etc. ). 

4. Integration of payload requirements into flight operation plans. (1.4.2, 1.4.3) 

5. Development of flight procedure documentation requirements. (2.2.2, 2. 2.4) 

6. Development of Station systems and payload test and integration plan details. 


B 16 




SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS AND PRODUCTS 



MANNED BASE INCREMENT 



PLANNING: 

to- 


GROUND OPERATIONS PLANNING 

W 


I1-B.3 



1. TACTICAL OPERATIONS PLAN (II -A): 

- PAYLOAD ASSIGNMENTS AND ALLOCATED RESOURCES 

- CREW NUMBER AND SKILL REQUIREMENTS 

- TRANSPORTATION SCHEDULES, VEHICLES, 
MASS/ELEMENT ASSIGNMENTS 

* STATION ACTIVITY REQUIREMENTS (MAINTENANCE, 
MODIFICATIONS GROWTH & EVOLUTION, TEST, C&O) 

- LOGISTICS ASSIGNMENTS AND UP/DOWN MANIFEST 

2. CURRENT INCREMENT RESOURCE AVAILABILITY INFORMATION 

(El) 

3. GROUND OPERATIONS MILESTONE SCHEDULE (II -B.1 ) 

4. GROUND OPERATIONS TRAINING PLANS (Ell) 

5. GROUND LOGISTICS SUPPORT ANALYSES (18) 

6. LAUNCH FACILITY SUPPORT 

7. ENGINEERING ANALYSES (E8-B) 
a GROUND PROCEDURE SUPPORT 


1. INCREMENT GROUND EXECUTION PLANS (E5,E6) 

2. TACTICAL OPERATIONS CHANGE REQUESTS (11 -A) 

3. GROUND SUPPORT TRAINING REQUIREMENTS (Ell) 

4. INCREMENT PLANS (E6) 

5. LOGISTICS REQUIREMENTS (18) 

6. LAUNCH FACILITY SUPPORT REQUIREMENTS 

7. DATA FOR ENGINEERING ANALYSES (E8-B) 

a MAINTENANCE AND OPERATIONS PROCEDURAL REQUIREMENTS 
(El) 

9. GROUND OPERATIONS TRAINING REQUIREMENTS (El 1 ) 


1. Analysis of resource availability, milestone schedules, training plans, engineering analyses for development of increment ground operations 
activities and timelines. Plans will schedule activities efficiently and effectively, within the guidelines put forth by the Tactical Operations Plan. 

2. Formulation of increment execution plans, submission to ground and logistics operations execution functions. 

3. Responsible for review and evaluation of ground operations progress in the ground and logistics operations functions. (3. 5, 4.9) 

4. Development of training requirements for ground operations personnel. (2.2.7,3.5,47) 

5. Development of ground maintenance and operations plans and procedures. (2.2) 
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SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS & PRODUCTS 



USER INTEGRATION AND 



ACCOMODATION SERVICES 



12 



1. SSIS OPS PLAN (E7) 

2. SELECTED USER LIST (P2-C) 

3. TACTICAL OPS PLAN (11-A) 

4. BASELINE SYSTEM CAPABILITIES & CONFIGURATION (19) 

5. I/F STANDARDS (II) 

6. SAFETY STANDARDS (16) 

7. USER ICD INPUTS (E9, El, E5) 

8. USER CONTRACTS & SERVICE AGREEMENTS (P8) 

9. OPS ASSESSMENTS (El, E3) 

10. USER-SYSTEM l/F DESIGN (E9-C) 


1. BILLABLE USER SERVICES DATA <P8) 

2. SYSTEM ICDs AND PAYLOAD INTEGRATION ANNEXES 
(E2,E4, USERS) 

3. USER l/F DESIGN REQUESTS (E8-C) 

4. USER -ELEMENT TEST PROCEDURES (E5) 

5. USER DELIVERABLE SCHEDULES (USERS) 

6. USER ICDs (E7.E5.E2) 

7. PAYLOAD-TO-INCREMENT FEASIBILITY AND COMPATIBILITY 
ANALYSES (I1-A.1.P9) 


1. Provides a single point of contact for all selected users into the Space Station organization and assumes responsibility for user satisfaction. 


2. Develops and manages user specific accommodation and interface control documents such as the user-station (user-platform) Interface Control 
Documents (ICDs), annexes, and transportation system ICDs. (1.2.4, 1.3.2, 1.3.4) 

3. Develops user-specific operations and integration plans. (1.2.1, 1.2.2, 1.4.2, 5.1.5) 

4. Conducts user-station (user-platform) integration reviews. (1.4.3) 

5. Contract support to Marketing and User Analysis function during support services contract negotiations. (1.1.1) 


6. Provides ongoing support to users to ensure user objectives are met. Provides definitions of standard and optional services to users. Arranges 
for optional services at user request. (1.4.4) 

7. Arranges and coordinates user training. 

8. Provides user requirements to operations analysis and integration functional area. (1 .2.4) 

9. Supports activities at payload development centers. 

10. Coordinates user requirements with element centers. (1.2.4) 

11. Coordinates with international partners/users. (5.6) 

12. Develops user ICDs. (1.3.2) 

13. Analysis of proposed payloads for feasibility for Station operations and compatibility with existing payloads. (1.3.1, 1.4.1) 
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SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS & PRODUCTS 


MANNED BASE & 
SUPPORT SYSTEMS 
ENGINEERING & 
INTEGRATION 
13 


1. DEVELOPMENT SCHEDULE (II) 

2. DEVELOPMENT BUDGET (17) 

3. INTERFACE STANDARDS (II) 

4. APPROVED CCB PRODUCTS (11) 

5. PROJECTED USER REQUIREMENTS (12) 

6. GROWTH & EVOLUTION PLAN (II ) 

7. TACTICAL OPERATIONS PLAN (II) 

8. STATION HARDWARE ICDs (E9) 

9. STATION AND SUPPORT SYSTEM SE4 1 


1. STATION AND PLATFORM CAPABILITY ENHANCEMENT 
SPECIFICATIONS (E9) 

2. GROUND SEGMENT CAPABILITY ENHANCEMENT 
SPECIFICATIONS (E9) 

3. ENGINEERING CHANGE REQUESTS (ECRs) (II ) 

4. COST ESTIMATES (II) 

5. IMPACT ASSESSMENTS (II) 

6. DEVELOPMENT SCHEDULES (E9) 

7. PROPOSED SYSTEMS CONFIGURATION AND OPERATIONS 
CONCEPT CHANGES (19) 

8. STATION INTERELEMENT ICDs (E9) 


1. Perform enhancement feasibility and supportability analyses (2.1.1, 2.4.1). Develop subsystem specification and performance requirements. 

2. Manage/perform advanced development programs. (2.1.1) 

3. Develop engineering change requests (ECRs). 

4. Provide cost estimates for proposed system enhancements. (5.4.3) 

5. Provide impact assessments for proposed system enhancements. 

6. Preparation and management of development programs, schedules. 

7. Analysis of present systems, user requirements, Station system goals and policies to assist in the development of the growth and evolution plan. 


SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS & PRODUCTS 



PLATFORM & 
SUPPORT SYSTEMS 



ENGINEERING & 



INTEGRATION 



14 



1. DEVELOPMENT SCHEDULE (II) 

2. DEVELOPMENT BUDGET (17) 

3. INTERFACE STANDARDS (II) 

4. APPROVED CCB PRODUCTS (II) 

5. PROJECTED USER REQUIREMENTS (12) 

6. GROWTH 4 EVOLUTION PLAN (II) 

7. TACTICAL OPERATIONS PLAN (II) 

8. PLATFORM HARDWARE ICDs (E9) 

9. PLATFORM AND SUPPORT SYSTEM SE4I 


1. Perform enhancement feasibility and supportability analyses. (2.1.1 

2. Manage/perform advanced development programs. (2.1.1) 

3. Develop engineering change requests (ECRs). 

4. Provide cost estimates for proposed system enhancements. (5.4.3) 


1. STATION AND PLATFORM CAPABILITY ENHANCEMENT 
SPECIFICATIONS (E9) 

2. GROUND SEGMENT CAPABILITY ENHANCEMENT 
SPECIFICATIONS (E9) 

3. ENGINEER NG CHANGE REQUESTS (ECRs) (II ) 

4. COST ESTIMATES (II) 

5. IMPACT ASSESSMENTS (II) 

6. DEVELOPMENT SCHEDULES (E9) 

7. FLIGHT ELEMENT TO LAUNCH VEHICLE ICDs (E9) 

8. PROPOSED SYSTEMS CONFIGURATION AND OPERATIONS 
CONCEPT CHANGES (19) 

9. PLATFORM INTERELEMENT ICDs (E9) 

2.4.1) Develop subystem specification and performance requirements. 


5. Provide impact assessments for proposed system enhancements. (2.3.2,2.3.3) 


6. Preparation and management of development programs, schedules. 


7. Analysis of present systems, user requirements, platform-system goals and policies to assist in the development of the growth and evolution 
plan. 
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SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS & PRODUCTS 



INFORMATION & NETWORK 



SYSTEMS ENGINEERING & 


w 

INTEGRATION 



15 



1. TACTICAL OPERATIONS PLAN (II) 

2. DEVELOPMENT SCHEDULE (II) 

3. DEVELOPMENT BUDGET (17) 

4. PROJECTED USER REQUIREMENTS (12) 

5. GROWTH AND EVOLUTION PLAN (II) 

6. APPROVED CCB PRODUCTS (II) 

7. 1/F STANDARDS (II) 

8. DATA SYSTEMS & UTILIZATION POLICIES (Pi) 


1 . INFORMATION & NETWORK SYSTEM CAPABILITY 
ENHANCEMENT SPECIFICATIONS (E7.E9) 

Z ENGINEERING CHANGE REQUESTS (ECRs) (II) 

3. COST ESTIMATES (II) 

4. IMPACT ASSESSMENTS (II) 

5. GROUND NETWORK ARCHITECTURE DEFINITION DOCUMENT 

6. DEVELOPMENT SCHEDULES (II ) 


1. Perform enhancement feasibility and supportability analyses. (2.1.1, 2.4.1) Develop subsystem specification and performance requirements. 

2. Manage/perform advanced information and network system development programs. (2.1.1) 

3. Provide engineering expertise for anomaly resolution. 

4. Develop engineering change requests (ECRs). 

5. Provide cost estimates for proposed system enhancements. (5.4.3) 

6. Provide impact assessments for proposed system enhancements. (2. 3. 2,2. 3. 3) 

7. Develop and control the ground network architecture definition document. Establish external interfaces necessary to coordinate and manage this 
funtional area. 

8. Preparation and management of development programs, schedules. 


SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS & PRODUCTS 



SAFETY, RELIABILITY/ 




MAINTAINABILITY & QUALITY 



ASSURANCE 

w 


16 



1. SAFETY REQUIREMENTS & DIRECTIVES (P5) 

2. USER SYSTEMS DESIGNS (12) 

3. PROPOSED SYSTEMS CONFIGURATION AND OPERATIONS 
CONCEPT CHANGES (II ,I9,E1) 

4. USER ICDs (12) 

5. SYSTEM ICDs (13,14) 


1. USER SAFETY STANDARDS (12) 

2. SAFETY ASSESSMENTS FOR ALL SPACE STATION FLIGHT 
SYSTEMS (II) 

3. SAFETY ASSESSMENTS FOR ALL USER SYSTEMS (12) 


1. Perform safety assessments of Space Station flight systems. 

2. Assess the safety of user systems, the user-to-system interfaces, and the user's proposed transaction management approach. (1.2.5) 

3. Provide independent reviews, analyses, and reports on proposed system configuration and operations concept changes. (5.1.11) 
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SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS & PRODUCTS 



BUDGET 



ADMINISTRATION & 



COST CONTROL 

W 


17 



1. OPERATIONS BUDGETS (P6) 

2. DEVELOPMENT BUDGETS <P6) 

3. EXPENDITURE REPORTS/OPERATIONAL VARIANCES (II .El ,E3) 


1 . OPERATIONS BUDGETS (11 ,E1 ,E3) 

2. DEVELOPMENT BUDGETS (13,14,15) 

3. BUDGET REQUESTS (PI) 

4. FUNDING ALLOCATIONS (ALL) 


1 . Develop budget schedules. (5.4) 

2. Distribute funds and assign controls. (5.4) 

3. Administer budget. (5.4) 


SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS AND PRODUCTS 


INTEGRATED 
LOGISTICS SYSTEMS 
18 




1. RESUPPLY/RETURN REQUIREMENTS (13,14) 

2. LOGISTICS REQUIREMENTS (II) 

3. USER ACCOMMODATION REQUIREMENTS (12) 


1 . MATERIAL REQUIREMENTS (E6) 

2. INTEGRATED LOGISTICS INPUTS TO TOP PLANNING PROCESS 

(H) 

3. LOGISTICS SUPPORT PLANS (II) 


1. Formulate plans for the use and procurement of integrated logistics facilities. (4.5) 

2. Develop and plan for logistics engineering capability. (4.1, 4.9) 

3. Analysis of Station/platform resupply requirements to aid in tactical operations planning. (4.1) 

4. Perform logistics support planning, coordination, analysis and integration. (4.1) 

5. Analysis of current user payload logistics support requirements, Station real-time problem/resolution impacts, to develop logistics support 
requirements for the next 16 flight increments. (4.1) 

6. Develop plans for maintenance integration. 
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SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS AND PRODUCTS 




CONFIGURATION 

CONTROL 

19 




1. ECR IMPACTS, ASSESSMENTS AND RECOMMENDATIONS 
(13, 14, El) 

2. TOP CHANGE REQUESTS (II -B) 

3. SYSTEM HARDWARE CHANGE REQUESTS (I1-B,E1,E2,...) 


1 . INTEGRATED SYSTEMS SPECIFICATION 

2. CONFIGURATION BASELINE LIST (I2,I6,E1,E3,P8) 

3. CHANGE APPROVALS (I1-B I E1,E2,...) 


1. Conduct system flight readiness reviews (FRRs). 

2. Manage changes to the baseline system through a formal review and approval process prior to directing hardware and software changes. 

3. Conduct periodic reviews and audits to verify that the change control process is effective. 

4. Establish and maintain a data collection and storage system which provides for tracking the change control documentation. These include change 
requests, dispositions, actions for change request, and verification reports. (2.3.2, 2.3.3) 


NOTE: This is not a 

Station organization 
function! 


SPACE STATION 

PROGRAM INTEGRATION FUNCTIONS AND PRODUCTS 



1. MANIFEST OPTIONS (I1-A.1) 


1. PAYLOAD-TO-INCREMENT ASSIGNMENT SUPPORT (I1-A.1) 

2. RECOMMENDATIONS AS TO ASSIGNMENT CHANGES (II -A.1 ) 

3. DECISION ASSISTANCE IN BORDERLINE SITUATIONS (I1-A.1) 


1 . A user working group function concerned with the analysis of possible payload-to-increment assignments. Makes recommendations based upon 
the assignment desirability from a user standpoint. 




SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 


MANNED BASE 
SYSTEM OPERATIONS 
El 




1. SSIS OPS PLAN (E7) 

2. FLIGHT INCREMENT PLAN (II) 

3. CONFIGURATION, GROWTH, & EVOLUTION PLAN (19,11) 

4. SYSTEM ICOs AND PAYLOAD OPERATION/INTEGRATION 
ANNEXES (12) 

5. CRITICAL PATH SCHEDULE OF INCREMENT PREPARATION 
ACTIVITIES (II) 


1 . WEEKLY RESOURCE ALLOCATION SCHEDULES & DAILY CAPs 
(E2) 

2 CREW TECHNIQUES AND PROCEDURES FOR OPERATING 
STATION SYSTEMS & USER SUPPORT EQUIPMENT 

3. TRAFFIC MANAGEMENT PROCEDURES 

4. OPS WORKSTATION (OWS) PROCEDURES 

5. EXT. MAINT & SERVICING FACILITY (EMSF) PROCEDURES 

6. COMMON SYSTEM REQUIREMENTS (II ) 

7. PROVISIONING REQUIREMENTS (II ) 

8. PROPOSED SYSTEMS CONFIGURATION AND OPERATIONS 
CONCEPT CHANGES (19) 

9. USER RESOURCE TEMPLATES (E2) 


1. Design, planning and development of flight operations for a specified period of time. (2.2.1) 

2. Operations planning and scheduling. (2.2.2) 

3. Crew procedures and techniques. (2.2.4) 

4. Ground procedures and techniques. (2.2.5) 

5. Support systems preparation. (2.2.9) 

8. Operations facilities support. (2.1.1, 2.1.2, 2.1.3) 

7. Flight operations support. (2.3.1) 

8. Data storage and data base design, operation, and maintenance. (2.3.2 modified) 

9. Operations support reconfiguration. (2.3.4) 

10. Technical data and documentation. (4.3) 

11. Operations working group activities. (5.3.3) 

12. Operations support to engineering simulations. (5.3.4) 

13. Station/user systems physical integration. (1.3.6) 

14. Development of preflight and real-time user resource templates. 
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SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 



MANNED BASE USER 



OPERATIONS 

to- 

w 

SUPPORT 



E2 



1. RESOURCE ALLOCATION TEMPLATES (El) 

Z KEY RESOURCE PARAMETERS (El) 

3. DISCIPLINE OPS PLAN 

4. DETAILED USER PLANS 

5. CURRENT DAILY STATION STATUS (El) 

6. USER REQUIREMENTS 

7. DAILY UPDATED RESOURCE ALLOCATIONS (El ) 


1. INTEGRATED PAYLOAD MISSION PLAN (El) 

2. RESOURCE RQMTS DELTAS (El) 

3. RESOURCE ALLOCATIONS AND PLANS (USERS) 

4. PAYLOAD CREW ACTIVITY PLAN (El) 

5. DAILY RESOURCE ALLOCATION UPDATES (USERS) 


1. Develop Integrated Payload Mission Plan as input to Ops Programming Tactical Plan. 


2. Generate the Summary Payload CAP. 


3. Update discipline allocations based upon system capabilities. 

4. Integrate payload user detailed procedures and command plans into PCAP. 

5. Review daily performance parameters, assess PCAP and update with IWG approval the user resource allocations. 


6. Verify adherence to safety requirements by users, assist in troubleshooting problems, enable user command and voice uplink, real-time conflict 
resolution. (1.4.4) 


7. Execution of user operations. (1.4.4) 


8. Define and update payload operations requirements. 

9. Work with DOC to resolve conflicts or appeal to IWG or POIC concerning resource allocation issues. 

10. Allocate resources to Users. (1.4.4) 

11. Provide an integrated assessment of user requirements based on revised daily activity plans from users. (1.4.4) 

12. Represents users to the POIC for planning activities. (1.4.4) 
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SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 


PLATFORM(S) SYSTEM | 
OPERATIONS 
E3 


1. SSISOPS PLAN (E7) 

2. PLATFORM OPERATIONS PLAN (II) 

3. CONFIGURATION, GROWTH & EVOLUTION PLAN (19,11) 

4. SYSTEM ICDs AND PAYLOAD OPERATION/INTEGRATION 
ANNEXES (12) 


1. WEEKLY RESOURCE ALLOCATION SCHEDULES (E4) 

2. COMMON SYSTEMS REQUIREMENTS (II) 

3. TRAFFIC MANAGEMENT PROCEDURES 

4. USER RESOURCE TEMPLATES (E4) 


1. Design, planning, and development of flight operations for a specified period of time. (2.2.1) 

2. Operations planning and scheduling. (2.2.2) 

3. Ground procedures and techniques. (2.2.5) 

4. Support systems preparation. (2.2.9) 

5. Operations facilities support. (2.1.1, 2.1.2, 2.1.3) 

6. Flight operations support. (2.3.1) 

7. Data storage and data base design, operation, and maintenance. (2.3.2 modified) 

8. Operations support reconfiguration. (2.3.4) 

9. Technical data and documentation. (4.3) 

10. Operations working group activities. (5.3.3) 

11. Operations support to engineering simulations. (5.3.4) 

12. Platform/user systems physical integration. (1.3.6) 
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SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 


PLATFORM USER 
OPERATIONS SUPPORT 
E4 


1. USER INSTRUMENT SCIENCE OPERATIONS REQUIREMENTS 
(USERS) 

2 SCIENCE/MISSION GUIDELINES 

3. RESOURCE ALLOCATIONS (E3) 

4. INTEGRATED PLATFORM TACTICAL OPERATIONS PLAN (II ) 

5. INSTRUMENT/SCIENCE SCHEDULING REQUIREMENTS 

6. DETAILED INSTRUMENT TIMELINES 

7. REVISIONS AS NEEDED TO INTEGRATED PLATFORM TOP 


1. INSTRUMENT/SCIENCE ALLOCATIONS 
2 INTEGRATED SCIENCE PLAN 

3. SCIENCE SCHEDULING TEMPLATE 

4. INTEGRATED TRANSFER OPS REQUIREMENTS (El ) 

5. PLATFORM SERVICING MAINTENANCE PLANNING INPUTS (El) 

6. NON-PROXIMITY ZONE TRANSFER OPS PLANNING INPUTS (El) 


1. Monitor platform performance and maintain the onboard systems configuration. 

2. Manage onboard systems to maintain system integrity and safety. 

3. Respond to platform contingencies by developing plans and procedures for restoring the platform to normal operations. 

4. Provide the focal point for leading anomaly investigations supported by the ESCs. 

5. Schedule system operations by integrating instrument data acquisition requirements, producing activity timelines, and transmitting timelines in 
the form of command files to the platform. 

6. Provide the direction for the development of malfunction procedures by the ESCs to support platform troubleshooting and checkout operations. 

7. Provide the lead to the Software Development Facility (SDF) for the development and implementation of onboard system software updates. 

8. Coordinate the platform payload operations activities performed in support of the UOFs such as the acquisition and distribution of platform and 
instrument data. (1.4.4) 

9. Coordinate the platform payload operations activities performed by other supporting ground elements such as the Flight Dynamics Facility, the 
Network Control Center and NASCOM. 

10. Analyze, process, and display platform engineering data. 

11. Maintain platform histories, configurations, and system performance measurements. 

12. Perform platform anomaly analysis and recommend procedural corrective actions. 

13. Develop maintenance and servicing ORU changeout and repair recommendations and procedures. 

14. Develop post-maintenance verification and checkout procedures. 

15. Support logistics and resupply activities. 

16. Maintain instrument health and safety, monitor instrument telemetry, analyze instrument performance. 

17. Plan and perform instrument operations, develop instrument operating timelines, generate and uplink instrument command sequences, update 
instrument operation procedures. 

18. Capture, process, archive, and analyze instrument telemetered data. 

19. Generate reports and scientific data products. 

20. Monitor platform performance and maintain the onboard system configuration during transfer operations. 

21. Provide the focal point for leading servicing and maintenance activities supported by the ESCs. 

22. Develop the coordinated operations requirements for the cooperating transfer operations elements. 

23. Schedule transfer operations activities, produce activity timelines and transmit timelines in the form of command files to the platform. 

24. Process, store, and distribute platform data. 

25. Monitor the operation and performance of cooperating elements. 

26. Coordinate transfer operations performed by other ground elements. 

27. Manage the handover of platform operations control between transportation and mission operators. 
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SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 


* 


PREFLIGHT/POSTFLIGHT 

OPERATIONS 

E5 




1. ASSEMBLY/DISASSEMBLY PROCEDURES 

2. MOVEMENT/tOADlNGtlNLOADING PROCEDURES 

3. VERIFICATION, TEST, AND CHECKOUT PROCEDURES 

4. SERVICING AND DESERVICING PROCEDURES 

5. TOXIC/HAZARDOUS MATERIALS HANDLING PROCEDURES 

6. FLIGHT SUPPORT EQUIPMENT INTEGRATOR PROCEDURES 

7. PROPRIETARY EQUIPMENT PROTECTION PROCEDURES 

8. MASS PROPERTIES MANAGEMENT 

9. POST-TEST DATA PROCESSING PROCEDURES 

10. SECURITY PROCEDURES 

1 1 . CREW SUPPORT PROCEDURES 

1 2. SSPF STORAGE AND MAINTENANCE PROCEDURES 

13. HAZARDOUS OPERATING PROCEDURES 

14. DATA PROCESSING AND STORAGE PROCEDURES 

1 5. FINAL MASS PROPERTIES DATA 

16. PRIME AND CONTINGENCY SITE POST LANDING OPS PLAN 

17. FACILITIES AND EQUIPMENT RQMT3 DOCUMENT 

18. INTEGRATED USER ELEMENT TEST PROCEDURE DEVELOPMENT 
SUPPORT 

19. HARDWARE DELIVERY SCHEDULES FOR PRELAUNCH 
PROCESSING 

20. MULTIFLOW MANAGEMENT SCHEDULES FOR PRELAUNCH 
PROCESSING 


1. Responsible for real-time execution of pre-increment ground operations. Areas of activity include payload processing, configuration, test and 
checkout, transportation as they relate to the following areas: 

(a) . Experiment integration (3.1.1) 

(b) . Structures/Systems (3.1.2) 

(c) . Laboratory modules (3.1.3) 

(d) . Habitation modules (3.1.4) 

(e) . Logistics carriers (3.1.5) 

(f) . Orbital maneuvering vehicle (3.1.6) 

(g) . Platforms (3.1.7) 

(h) . International element support. (3.1.8) 

2. Responsible for ground system maintenance. (3.1.9) 

3. Operations planning and analysis. (3.3) 

4. Paytoad/payload facility support. (3.4) 

5. Technical data and documentation. (4.3) 

6. Test, verification, and assembly operations. 


1 . FLIGHT INCREMENT PLANS (II) 

2. SYSTEM ICDs AND PAYLOAD INTEGRATION ANNEXES (12) 

3. SSIS OPS PLAN (E7) 

4. CRITICAL PATH SCHEDULE OF INCREMENT PREPARATION 
ACTIVITIES (II) 
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SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 


INTEGRATED LOGISTICS 
OPERATIONS 
E6 


1. FLIGHT INCREMENT PLANS (II) 

2. GROWTH & EVOLUTION PLAN (II) 

3. CRITICAL PATH SCHEDULE OF INCREMENT PREPARATION 
ACTIVITIES (II) 


1. SHIPPING/RECEIVING PROCEDURES 

2. LFttJ MAINTENANCE & REPAIR PROCEDURES 

3. HARDWARE IMPACT REFURBISHMENT PROCEDURES 

4. FLIGHT AND GROUND HARDWARE CALIBRATION PROCEDURES 

5. GROUND TRANSPORTATION REQUIREMENTS 

6. REPAIR LEVEL ANALYSES 

7. NVENTORY MANAGEMENT SYSTEM OPS PROCEDURES 

8. MAINTENANCE WORK AREA (MWA) PROCEDURES 

9. TRAINING/SIMULATOR FACILITY REQUIREMENTS (II) 


1. Maintenance for ground and space based equipment in operational condition. (4.2) 

2. Technical data and documentation. (4.3) 

3. Logistics facilities maintenance and operations. (4.5) 

4. Packaging, handling, storage, and ground transportation. (4.6) 

5. Personnel and training. (4.7) 

6. Ground Support Equipment acquisition. (4.8) 

7. Repair management for space and ground system Orbital Replacement Units (ORUs). 

8. Resupply/Return management. 


SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 


* 


INFORMATION SYSTEM 
OPERATIONS 
E7 




1 . INTERFACE STANDARDS (II ) 1 . ICD INPUTS (12) 

2. FLIGHT INCREMENT PLANS (II ) 2. SSIS OPS PLAN (El ,E3,E5) 

3. CAPABILITY ENHANCEMENT SPECS FOR STATION & 

PLATFORMS (15) 

4. CAPABLrTY ENHANCEMENT SPECS FOR GROUND SEGMENTS 
(15) 

5. SYSTEM ICDs AND PAYLOAD INTEGRATION ANNEXES (12) 

6. SSIS OPS PUN (12) 

7. DESIGN AND ENGINEERING DATA ON GROUND 
SEGMENT EHNANCEMENTS/MODIFICATIONS (E8) 


1. Network requirements integration in preparation for flight increment operations. (2.3.3) 

2. Pre-increment and real-time information systems operations support to Station Systems Support Center (SSSC), Payload Operations Integration 
Center (POIC), and users. (2.3.2) 

3. Development and maintenance of the Space Station Information System (SSIS) Operations Plan. (2.3.2,2.3.3) 

4. Information systems support to non-real-time facilities (Policy, Integration levels), real-time input to information systems planning, data 
sharing, storage, etc. 
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SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 




SUSTAINING ENGINEERING: 
SPACE SYSTEMS 
E8-A 




1 . STATION AND PLATFORM CAPABILITY ENHANCEMENT 
SPECIFICATIONS (13,14) 

2. GROWTH AND EVOLUTION EVALUATION REQUESTS (P4) 

3. INTERFACE STANDARDS (II) 

4. PAYLOAD INTEGRATION ANNEXES (12) 

5. DEVELOPMENT SCHEDULES (13,14) 

6. STATION/PLATFORM SYSTEMS PERFORMANCE EVALUATIONS 
(E1,E3) 


I. DESIGN AND ENGINEERING DATA ON STATION AND PLATFORM 
Z ORU MAINTENANCE PROCEDURES 

3. MAINTENANCE DIAGNOSTIC PROCEDURES 

4. SYSTEM PERFORMANCE EVALUATIONS (El ,P5) 

5. ENGINEERING CHANGE REQUESTS (ECRs) (II) 

6. ENGINEERING ASSESSMENTS (II) 

7. PERFORMANCE DEGRADATION ANALYSES (El) 

8. STATION/PLATFORM HARDWARE INTERFACE CONTROL 
DOCUMENTS (ICDs) (13,14) 

9. FLIGHT ELEMENT TO LAUNCH VEHICLE ICDs (P7) 

10. INTERELEMENT ICDs (13,14) 

I I . PREVENTATIVE MAINTENANCE REQUIREMENTS (II ) 

12. GROWTH AND EVOLUTION PLAN EVALUATIONS (P4) 


1. Design and engineering of Station and platform enhancements/modifications. (2.1.1, 2.4.2) 


2. Support the feasibility and supportability analyses of proposed enhancements and modifications. (2.1.1, 2.4.1) 

3. Subsystem integration and verification. (2.4.4) 


4. Perform Station system advanced technology programs (as assigned). (2.1.1) 

5. Station reconfiguration and payload installation requirements. Includes schematics, installation/removal instruction and software products. 

6. Modification/enhancement implementation. (2.4.3) 


7. Provide engineering expertise for anomaly resolution. 


8. Provide analyses of degradations of performance and windows. (SSORD 3.1. 4.2.3) 

9. Maintain and update Station/platform hardware ICDs. 

10. Engineering support analysis for loads, mass, RF, and thermal, for Station elements. 

11. Analysis of current Station maintenance status, and subsequent issue of periodic Station preventative maintenance requirements and procedural 
details to Station Operations and Maintenance Planning function. 


SPACE STATION 

PROGFIAM EXECUTION FUNCTIONS & PRODUCTS 


SUSTAINING ENGINEERING: 
GROUND SYSTEMS 
E8-B 




1. CAPABtLTTY ENHANCEMENT SPECIFICATIONS 
GROUND SEGMENT (13,14) 

2. INTERFACE STANDARDS (II) 

3. PAYLOAD INTEGRATION ANNEXES (12) 

4. DEVELOPMENT SCHEDULES (13,14) 


1 . DESIGN AND ENGINEERING DATA ON GROUND SEGMENT 
ENHANCEMENT/MODIFICATIONS 

2. ENGINEERING CHANGE REQUESTS (ECRs) (II) 

3. ENGINEERING ASSESSMENTS (II) 

4. PREVENTATIVE MAINTENANCE REQUIREMENTS (II) 


1. Design and engineering of ground segment enhancements/modifications. (4.5, 2.1,1, 2.4.2) 

2. Maintenance of interfacing ground support equipment. 

3. Maintenance and development of non-interfacing ground systems, including console equipment, simulators/trainers, payload integration and 
verification facilities, etc. 
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SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 



SUSTAINING ENGINEERING: 



PAYLOAD INTERFACE 



ENGINEERING & INTEGRATION 



E8-C 



1 . USER INTERFACE DESIGN REQUESTS (12) 1 - 

2. INTERFACE STANDARDS (II) 2. 

3. PAYLOAD INTEGRATION ANNEXES (12) 3. 

4. DEVELOPMENT SCHEDULES (13,14) 4. 

5. USER ICDs (12) 5. 


USER ICD INPUTS (12) 

USER-SYSTEM L/F DESIGN (12) 

ENGINEERING CHANGE REQUESTS (ECRs) (II) 
ENGINEERING ASSESSMENTS (II) 

INTEGRATED PLAN ENGINEERING ANALYSES (II -A) 


1. User-system interface engineering. Includes user-system interface designs as requested/necessary. (1.3.5) 

2. User-system/subsystem integration, verfication, and compatibility assessments. (1.3.1) 

3. Station reconfiguration and payload installation requirements. Includes schematics, installation/removal instruction and software products. 

4. Provide engineering expertise for anomaly resolution. 

5. Engineering support analysis for loads, mass, RF, and thermal, for payload elements. 

6. Performance of plan engineering analyses for Integrated Operations Planning function to aid in optimization, tradeoffs, and conflict resolution in 
the integration of Station and Payload Support Plans. 

SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCT S 




CONFIGURATION MANAGEMENT: 
SPACE SYSTEMS 
E9-A 




1. HARDWARE ACCEPTANCE DATA PACKAGES 

2. SOFTWARE DELIVERABLE DATA PACKAGES 

3. NTERFACE CONTROL DOCUMENTS 

4. INTERFACE REVISION NOTICES (IRNs) 

5. SYSTEM REQUIREMENT REVIEWS 

6. PRELIMINARY DESIGN REVIEWS 

7. CRITICAL DESIGN REVIEWS 


1. DESIGN IMPLEMENTATION PLANS 

2. SPECIFICATION TREE 

3. CONTRACT CHANGE ORDERS 

4. CHANGE STATUS REPORTS 

5. DESIGN BASELINE (ENGINEERING DRAWINGS) 

6. SYSTEM CERTIFICATION (SAFETY/ENVIRONMENTAL) 

7. DESIGN REVIEW RESULTS 

8. INSTALLATION NOTICE OF COMPLETION 

9. AS-INSTALLED CONFIGURATION STATUS REPORT 

10. MODIFICATION STATUS 


1 . Selecting end items of hardware and software to come under configuration control. 

2, Develop and maintain baseline identification of hardware and software under configuration control. (2.3.4) 


3. Develop and maintain engineering documentation. 

4. Control hardware and software such that demonstrated physical status and performance satisfy mission, 
safety, and security requirements. 


5. Closing out configuration change directives upon completion of the configuration verification and configuration accounting processes. 

6. Conduct reviews to assure that the design of the changes to the baseline configuration satisfies approved requirements (mission, safety, 
security,...). 


7. Conduct reviews, tests, inspections, etc., to assure that the hardware or software end items conform to the released design documentation. 


8. Conduct reviews, tests, inspections, etc., to assure that the modifications have been incorporated in accordance with the configuration change 
directive (i.e. verify "as-built" is the same as "as-designed"). 
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SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 


* 


CONFIGURATION MANAGEMENT: 
GROUND SYSTEMS 
E9-B 




1. HARDWARE ACCEPTANCE DATA PACKAGES 

2. SOFTWARE DELIVERABLE DATA PACKAGES 

3. INTERFACE CONTROL DOCUMENTS 

4. INTERFACE REVISION NOTICES (IRNs) 

5. SYSTEM REQUIREMENT REVIEWS 

6. PRELIMINARY DESIGN REVIEWS 

7. CRITICAL DESIGN REVIEWS 


1. DESIGN IMPLEMENTATION PLANS 

2. SPECIFICATION TREE 

3. CONTRACT CHANGE ORDERS 

4. CHANGE STATUS REPORTS 

5. DESIGN BASELINE (ENGINEERING DRAWINGS) 

6. SYSTEM CERTIFICATION (SAFETY/ENVIRONMENTAL) 

7. DESIGN REVIEW RESULTS 

8. INSTALLATION NOTICE OF COMPLETION 

9. AS-INSTALLED CONFIGURATION STATUS REPORT 

10. MODIFICATION STATUS 


1. Selecting end items of hardware and software to come under configuration control. 

2. Develop and maintain baseline identification of hardware and software under configuration control. (2.3.4) 

3. Develop and maintain engineering documentation. 

4. Control hardware and software such that demonstrated physical status and performance satisfy mission, safety, and security requirements. 

5. Conduct reviews, tests, inspections, etc., to assure that the hardware or software end items conform to the released design documentation. 

6. Conduct reviews, tests, inspections, etc., to assure that the modifications have been incorporated in accordance with the configuration change 
directive (i.e. verify "as-built" is the same as "as-designed"). 


SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 


CONFIGURATION MANAGEMENT: | 
PAYLOAD INTERFACES 
E9-C 


1. PAYLOAD-TO-STATtON ICDs/ANNEXES (12) 1. CHANGE REQUEST APPROVALS/DISAPPROVALS (12) 

2. PAYLOAD-TO-STATION ICD/ANNEX CHANGE REQUESTS (12) 


1. Maintain configuration control of payload-to-Station/platform ICDs and Annexes. 

2. Determine the appropriate level of change control for all payload-to-Station/platform interface documentation. 

3. Determine when payload to Station/platform interface documentation goes under change control. 
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SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 




CONFIGURATION MANAGEMENT: 
EXECUTION-LEVEL OPS PLANS & 
PROCEDURES 
E9-D 




1. FLIGHT DATA FILE (El) 1 . CHANGE REQUEST APPROVALS/DISAPPROVALS (II -B) 

2. OMSRDs (E5) 

3. OMIs (E5) 

4. CHANGE REQUESTS 


1. Maintain configuration control over Station flight data file, Operations and Maintenance Specifications Requirements Documents (OMSRDs), and 
Operational Maintenance Instructions (OMIs). 

2. Determine the appropriate level of control for the above documents. 

3. Determine when the above documents go under change control. 


SPACE STATION 

PROGRAM EXECUTION FUNCTIONS & PRODUCTS 



SAFETY, RELIABILITY/ 



MAINTAINABILITY & QUALITY 



ASSURANCE 



E10 



1 . LAUNCH SITE OPERATIONS (E5) 

2. LOGISTICS OPERATIONS PLANS (E6) 

3. FLIGHT OPERATIONS SUPPORT PLANS 
(E1,E2,E3,E4) 


1. LAUNCH SITE SR/M&QA PROCEDURES (E5) 

2. LOGISTICS SUPPORT SR/M&QA PROCEDURES (E6) 

3. GROUND OPERATIONS SR/M&QA PLAN (E5.E7) 

4. FLIGHT OPERATIONS SAFETY ASSESSMENTS (E1,E2,E3,E4) 


1. Implements and ensures execution level compliance with the safety, reliability/maintainability and quality assurance policies and requirements of 
the Space Station. 
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SPACE STATION 

PROGRAM EXECUTION FUNCTIONS AND PRODUCTS 


* 


OPERATOR TRAINING 
Ell 




1. CREW, FLIGHT CONTROLLER TRAINING REQUIREMENTS (II) 1. CREW, FLIGHT CONTROLLER TRAINING PLANS (II) 

2. GROUND SUPPORT OPERATIONS TRAINING REQUIREMENTS (II) 2. GROUND SUPPORT OPERATIONS TRAINING PLANS (II) 

a SPACE AND GROUND OPERATIONS SCHEDULES (II) 

4. TRAINING FACILITY AVAILABILITIES 

5. PERSONNEL SKILL REQUIREMENTS (II ) 


1. Analysis of Station and ground personnel training requirements and schedules for development of appropriate training plans and procedures. 
(2.2.7) 

2. Organization and scheduling of inter-facility training activities such as large-scale simulations, dry runs, etc. (2.2.7) 

3. Executes crew, flight controller, ground support personnel training plans. (2.2.8) 
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APPENDIX C 


BASELINE PROGRAM FACILITIES ASSESSMENT 

The facility listing in this Appendix was originally compiled by the Level B Space Station Program Office as a 
working tool in defining the required facilities to support Space Station assembly and development. It was 
anticipated that this list would be used to relate the development work being performed within the various 
NASA Centers to work conducted by their prime contractors as part of an effort to avoid duplication and 
overlap of facilities in the Development Phase of the Program. 

However, as a better definition of annual operations costs was formulated by the Program, this list was 
expanded to include all of the projected facilities required for both development and subsequent mature 
operations. In this manner, it is noped that early scrutiny of the facilities planned for use in the Development 
Phase could result in an established plan for phasing out any which will not be required during Mature 
Operations. Similarly, early identification of facility requirements for mature operations could help find areas 
of synergy with currently planned development facilities which would optimize Program resources. 

The SSOTF conducted a limited review of this augmented list and categorized the facilities into three groups: 
(1) those which were mandatory for Station operations under the SSOTF Recommended Framework; (2) those 
whose operational functions were either not well understood or would be required on an as needed basis only; 
and (3) those which would not be required at all during the Mature Operations Phase. This grouping was then 
subdivided into Space Station unique facilities, and facilities which would be shared with other programs in an 
effort to more accurately scope the size of the facilities support burden required to run the Station Program. 

Given the limited amount of time and information available to its members, this review is only a preliminary 
effort at identifying the full extent of facilities requirements for the Program. The Task Force recommends that 
the Space Station Program initiate further study of the projected facility support requirements and their 
associated opertional costs to determine exact areas of overlap and synergy in planned facilities. 


Space Station Program Evaluation 
Facility/Capability all Program Phases 
Working Paper 


FACILITIES/CAPABILITIES FACILITY DESCRIPTIONS WP 


MANDATORY ■ SPACE STATION UNIQUE 

SOFTWARE SUPPORT ENVIRONMENT (SSE) FOR DEVELOPMENT OF TOOLS AND RULES FOR SS SOFTWARE A' 

SERVICE & VERIF FACILITY MOCKUP DELIVERABLE FROM WP4 PRIME GSFC 

S/W PRODUCTION FACILITY FACILITY TO PRODUCE OR VERIFY APPLICATIONS S/W GSFC 

ENGINEERING ANALYSIS FACILITY (CDOS) ENGINEERING DATA ANALYSIS SUPPORT TO CDOS GSFC 

INTEG. TEST & VERIFICATION FACILITY EXPERIMENT INTEGRATION & CHECKOUT FACILITY GSFC 

PLATFORM SUPPORT CENTER (CDOS) CONTROL FACILITY FOR PLATFORMS GSFC 

SERVICING SUPPORT CENTER (CDOS) CONTROL ROOM FOR SERVICING FACILITY GSFC 

SPACE STATION TRAINING FACILITY (SSTF) PRIMARY CREW & CONTROLLER TRAINING FACILITY JSC 

STATION PROXIMITY OPERATIONS TRAINER USED FOR RENDEZVOUS/PROX OPS/MRMS OPERATIONS JSC 

TRAINING 

MEDIUM FIDELITY LAB MODULE SIMULATORS LAB SYSTEMS/PAYLOADS TRAINER JSC 

FLIGHT CONTROLLER TRAINING FACILITY PROVIDE TRAINING ENVIRONMENT FOR CONTROLLERS JSC 

SPACE STATION SYSTEMS TRAINER DISTRIBUTED SYSTEMS TRAINER JSC 

MULTI-SYSTEMS INTEGRATION FACILITY (MSIF) PERFORM INTEGRATION AND VERIFICATION OF SYSTEMS S/W JSC 

MANNED AND MANIPULATOR SYS INTEG TESTBED MANNED RMS/MRMS SYSTEMS INTEG & MOCKUPS JSC 

TAVERNS PROTOTYPE/TESTBED FOR DMS/DMS DEVELOPMENT JSC 

SPACE STATION SUPPORT CENTER (SSSC) PRIMARY SYSTEMS/FLIGHT CONTROL CENTER JSC 

SS AUTOMATION INTEG & ASSEMBLY FACILITY STRUCTURES AND MECHANISMS LABORATORY JSC 

S/W PRODUCTION FACILITY FACILITY TO PRODUCE OR VERIFY APPLICATIONS S/W JSC 

SPACE STATION PROCESSING FACILITY (SSPF) DEDICATED HORIZONTAL PROCESSING FACILITY KSC 

S/W PRODUCTION FACILITY FACILITY TO PRODUCE OR VERIFY APPLICATIONS S/W KSC 

* MODS TO SSPF: MASTER INTEGRATION FACILITY ENHANCEMENT OF TEST/CHECKOUT CAPABILITY IN SSPF KSC 

* LOGISTICS OPS CENTER FACILITY TO STOCK, REPAIR, SUPPORT LOGISTIC FUNCTION KSC 

S/W PRODUCTION FACILITY FACILITY TO PRODUCE OR VERIFY APPLICATIONS S/W LERC 

OPS SUPT CNTR. (ESC) ENGINEERING SUPPORT CENTER FOR POWER SYSTEMS (WP4) LERC 

PAYLOAD TRAINING INTEGRATION FACILITY (PT1F) SIMULATOR USED FOR PRE-INCREMENT CREW TRAINING MSFC 

* PAYLOAD OPERATIONS INTEGRATION CENTER (POIC) PRIMARY USER OPERATIONS INTEGRATION CENTER MSFC 

GROUND CONTROL EXPERIMENT LAB (GCEL) FOR VERIFICATION/CHECKOUT OF SS EXPERIMENT EQUIPMENT MSFC 

l/F VERIF/SIMULATION FACILITY SUPPORTS l/F VERIFICATION FOR RACKS OF USER EQUIPMENT MSFC 

ONE G MOCKUP (OPS DEVELOPMENT COMPLEX) MOCKUP OF THE MODULES AND NODES MSFC 

S/W PRODUCTION FACILITY FACILITY TO PRODUCE OR VERIFY APPLICATIONS S/W MSFC 

CORE MOD INTEG. FAC/CORE MODULE SIM. FAC CORE MODULE INTEGRATED SYSTEM SIMULATOR MSFC 
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Space Station Program Evaluation 
Facility/Capability all Program Phases 
Working Paper (Continued) 


MANDATORY ■ SHARED WITH OTHER PROGRAMS 


MISSION CONTROL CENTER (MCC-H) 

SHUTTLE MISSION SIMULATOR (SMS) 

EMU TRAINER 

DATA HANDLING CENTER (CDOS) 

WEIGHTLESS ENVIR. TRAINING FACILITY (WETF) 

SYSTEMS ENG. SIMULATOR-STATION ON-ORBIT SIMS 

VLS P/L PROCESSING FACILITY 

MODS TO PADS A&B 

NEUTRAL BUOYANCY FACILITY 

HUNTSVILLE OPERATIONS CENTER (HOSC-MSFC ESC) 


SHUTTLE CONTROL CENTER JSC 

SHUTTLE MISSION SIMULATOR USED FOR JOINT OPERATIONS JSC 
EVA/SUIT TRAINER JSC 

PART OF THE CUSTOMER DATA OPS SYSTEM GSFC 

WATER IMMERSION TRAINING FACILITY JSC 

SHUTTLE ENG. SIMULATOR FOR STS/SS OPS SIMULATIONS JSC 

VANDENBURG LAUNCH SITE PAYLOAD PROCESSING FACILITY KSC 
MODIFICATIONS TO LAUNCH PADS ALLOWING LATE ACCESS KSC 

WATER IMMERSION TRAINING FACILITY MSFC 

WP1 ENGINEERING SUPPORT CENTER MSFC 


REQUIRE MORE DATA/USE ON AN AS NEEDED BASIS -SPACE STATION UNIQUE 


DMS TEST BED GSFC 

THERMAL TEST BED GSFC 

INTEG. LOGISTICS SYSTEM NODE GSFC 

DMS TEST BED JSC 

ADVANCED SYSTEMS DEVELOPMENT LAB JSC 

USER OPERATIONS FAC JSC 

EVA-LIFE SUPPORT SYSTEM TEST BED JSC 

EVA TEST BED JSC 

C&T/DMS SYSTEM TEST BED JSC 

TRACK SYS TEST BED JSC 

AC&S SYSTEM TEST BED JSC 

THERMAL SYSTEM TEST BED JSC 

PROP SYSTEM TEST FACILITY JSC 

AUTOMATION TEST BED JSC 

ENVIRONMENTAL CONTROL LIFE SUPPORT TEST BED MSFC 

, ELECTRICAL SYSTEM BREADBOARD MSFC 

ECLSS SYSTEM SIMULATOR MSFC 

ACS TEST BED MSFC 

TEST STAND 300(H/0) MSFC 


REQUIRE MORE DATA/USE ON AS NEEDED BASIS - SHARED WITH OTHER PROGRAMS 


FLIGHT DYNAMICS FACILITY GSFC 

LIQUID HELIUM TESTBED GSFC 

CONTROL & MONITORING TESTBED JSC 

KC-135 JSC 

RADIO FREQUENCY COMMUNICATION LAB JSC 

THERMAL VACUUM CHAMBERS • NOT MAN RATED JSC 

ELECTRO-MAGNETIC INTERFACE TEST FACILITY JSC 

ELECTRONIC SYSTEMS TEST LABORATORY (ESTL) JSC 

COMM SYS SIM LAB (CSSL) JSC 

SYSTEMS OPS DEVELOPMENT LAB JSC 

EPDC LAB/TESTBED JSC 

GN&C LAB JSC 

THERMAL VACUUM - MAN RATED (CHAMBER B) JSC 

ANECHOIC CHAMBER JSC 

E&D COMPUTATIONAL FACILITY JSC 

* COMPUTATIONAL FACILITY KSC 

LARGE ATOMIC OXYGEN FACILITY LERC 

OPTICS FACILITY LERC 

MATERIALS COMPATIBILITY LAB LERC 

SOLAR CELL LAB LERC 

TANK 5/6 LERC 

BATTERY LABS LERC 

CMG VAULT MSFC 

ATOMIC OXYG BEAM TEST FACILITY MSFC 

ON-ORBIT REPAIR FACILITY (PROCESS TECH FAC) MSFC 

SPACE ENVIRONMENTAL EFFECTS FACILITY MSFC 

MANUFACTURING FACILITY MSFC 

OMV/FTS l/F SIMULATOR MSFC 
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Space Station Program Evaluation 
Facility/Capability all Program Phases 
Working Paper (Continued) 


REQUIRE MORE DATA/USE ON AS NEEDED BASIS - SHARED WITH OTHER PROGRAMS (Continued) 

SPACE DEBRIS FACILITY MSFC 

DYNAMIC TEST STANDS MSFC 

ROBOTIC LAB MSFC 

MECHANISMS TESTBED/FLAT FLOOR MSFC 

MATERIALS PROCESSING SYSTEMS TESTBEDS MSFC 

PROPULSION TESTBED MSFC 

NOT REQUIRED IN MATURE OPERATIONS ■ SPACE STATION UNIQUE 

CUSTOMER COORDINATION CNTR/NODES (CDOS) GSFC 

SPACE PROP FACILITY (PLUMBROOK) LERC 

NOT REQUIRED IN MATURE OPERATIONS • SHARED WITH OTHER PROGRAMS 

MULTIPLE APPLICATIONS CONTROL CNTR (CDOS) GSFC 

THERMAL VACUUM THERMAL SYSTEMS JSC 

SPACE STATION HAZARDOUS PROCESSING FAC (SSHPF) KSC 

PAYLOAD OPERATIONS CONTROL CENTER (POCC) MSFC 

POCCTRNGB4755 MSFC 


*OTF IDENTIFIED REQ 
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INDEX OF DEFINITIONS 


ACCOMMODATE 

AD-HOC 

ASSEMBLY 

ASTRONAUT 

ATTACHED PAYLOADS 

AUTOMATION 

AUTONOMY 

CAPABILITY 

CAPACITY 

CARGO 

CENTRALIZED 

CERTIFICATION 

CHECKLIST 

CHECK-OUT 

CO-ORBIT 

CO-ORBITING PLATFORMS 

COLUMBUS MODULE 

COMMAND AND CONTROL ZONE 

COMMONALITY 

CONCEPT 

CONSUMABLES 

COSTING 

CREW 

CREWMEMBER 

CUSTOMER 

DISCIPLINE OPERATIONS CENTER 
DISTRIBUTED SYSTEMS 
DOCKING 
ENCLAVE 

ENGINEERING SUPPORT CENTER 
EVOLUTION 

EXECUTION (OPERATIONS) 

EXPENDABLE LAUNCH VEHICLE (ELV) 

EXPENDABLES 

EXPERIMENT 

EXTRAVEHICULAR ACTIVITY (EVA) 

FLIGHT 

FLIGHT RULES 

FRAMEWORK 

GROUND (BASED) OPERATIONS 
GROWTH 

HEALTH MAINTENANCE FACILITY 
IN-SITU 

INCREMENT (OPERATIONS) 
INFRASTRUCTURE 

INITIAL OPERATIONAL CAPABILITY (IOC) 
INTEGRATION 
INTERNATIONAL PARTNER 
INTRAVEHICULAR ACTIVITIES (IVA) 
INVESTIGATOR 

JAPANESE EXPERIMENT MODULE (JEM) 

KIWI 

Ku BAND 

LABORATORY 

LIFE CYCLE COST 


LOGISTICS 

LOGISTICS OPERATIONS CENTER 

MAINTAIN 

MAINTAINABILITY 

MAINTENANCE 

MANIFESTING 

MANNED BASE 

MATURE OPERATIONS PHASE 

MISSION 

MISSION SET 

MODULE 

ORBITAL MANEUVERING VEHICLE 
ORBITAL REPLACEMENT UNIT 
PARTNER 
PAYLOAD 

PAYLOAD OPERATIONS 
PAYLOAD OPERATIONS INTEGRATION CENTER 
PERMANENT MANNED PRESENCE 
PLATFORM 

PLATFORM SUPPORT CENTER 
POLAR ORBIT PLATFORM 
PRICING 

PROXIMITY OPERATIONS 

QUALIFICATION 

REAL-TIME 

REAL-TIME SUPPORT 

REGIONAL OPERATIONS CENTER 

S-BAND 

SCENARIO 

SERVICEABLE SATELLITE 
SERVICING 

SPACE (BASED) OPERATIONS 

SPACE PLATFORM 

SPACE STATION 

SPACE STATION OPERATIONS 

SPACE STATION PROCESSING FACILITY 

SPACE STATION PROGRAM 

SPACE STATION SUPPORT CENTER 

SPACE SYSTEMS 

SPACE TRANSPORTATION SYSTEM 
STS CREW 

STRATEGIC (OPERATIONS) 

STRATEGIC (PLANNING) 

STRATEGY 

SUSTAINING ENGINEERING 
TACTICAL (OPERATIONS) 

TELESCIENCE 

TRAFFIC MANAGEMENT ZONES 
TRANSFER OPERATIONS 
TRANSPARENT TECHNOLOGY 
UNMANNED PLATFORMS 
USER 

USER OPERATIONS FACILITY 
UTILIZATION 
VALIDATION 
VERIFICATION 
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SPACE STATION OPERATIONS TASK FORCE 


DEFINITIONS OF TERMS 


ACCOMMODATE 

To support in a general hardware, software, and 
personnel services context. 

Note: 

Throughout the Space Station Program the term 
'accommodate' should be used and interpreted as 
establishing the necessary hardware, software, 
and/or procedures for the associated relationship. 


AD-HOC 

For a specific purpose. 

ASSEMBLY 

Placing in orbit, arranging in flight configuration, and 
interconnection of the various elements and systems 
of the Space Station. 

ASTRONAUT 

One of a contingent of astronauts, each qualified to 
operate as a commander or crew member of a 
spacecraft, including the Space Station, 

ATTACHED PAYLOADS 

Payloads located on the Space Station structure 
outside the pressurized modules. 

AUTOMATION 

The operation or control of a process, equipment, or a 
system in a manner essentially independent of 
external influence or control; the condition of being 
automated. 


AUTONOMY 

Independence of a flight system from direct real-time 
control by the ground. The condition of being 
autonomous; self-governing community. 

CAPABILITY 

A functional attribute of any element of the Space 
Station Program. 

CAPACITY 

Quantity generally associated with an existing 
capability. 

CARGO 

Complement of equipment to be delivered to orbit by 
the Space Shuttle or an expendable launch vehicle; 
also an element of this overall complement. 

CENTRALIZED 

Having one source for management and control 
actions. Focusing specific capabilities in one strategic 
location. Organized in a manner so that there is a 
single source of authority for all command, control 
and direction of related functions. 

CERTIFICATION 

See VERIFICATION 


CHECKLIST 

A booklet or the equivalent data base file containing 
system operating procedures or integrated flight 
procedures in an abbreviated form to support various 
station, platform or payload activities. 

CHECKOUT 

Test activities that verify the readiness of hardware 
and/or software for its intended use. 

CO-ORBIT 

In the same, or nearly the same orbit as another 
object, particularly with respect to the orbit period. To 
orient so as to require very little final control velocity 
such as to execute a rendezvous, docking, berthing, or 
tending mission. 

Notes: 

In the strictest sense, two co-orbiting objects 
would be coincident. In practice, and in any 
context associated with the Space Station Program, 
a co-orbiting object would have the same period, 
eccentricity, ascending node and argument of 
perigee; but would be at a slightly different right 
ascension (i.e., stable station-keeping ahead of, or 
behind the Space Station). 

CO-ORBITING PLATFORMS 

A Space Platform with the same average orbital 
period, inclination, and node as the Space Station, and 
maintaining its orbit path along that of the Space 
Station. 

COLUMBUS MODULE 

The laboratory module provided by ESA that is to be 
part of the baseline configuration of the Space 
Station. 

COMMAND AND CONTROL ZONE 

The traffic management zone within which the station 
crew serves as tne primary control authority for all 
approaching and departing vehicles. A volume 
encompassed at 20 nautical miles above and below, 20 
nautical miles fore and aft, and 5 nautical miles to 
port and starboard of the Manned Base. 

COMMONALITY 

The use of the same or similar vehicles, interfaces, 
modules, systems, or technical or operational 
approaches in two or more programs with the primary 
objective of improving operations effectiveness or 
reducing costs in one or more of the programs. Using 
components that are interchangeable between the 
manned base, the co-orbiting space platform, and the 
polar orbiting platform, and between elements of the 
manned base. 

CONCEPT 

An idea developed to the extent that stated objectives 
may be supported, that technical, economic and 
management approaches can be assessed, and that 
different concepts with the same, or similar objectives 
may be assessed for their relative merits. 
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DEFINITIONS OF TERMS 
(Continued) 


CONSUMABLES 

The materials that are expended during the course of 
meeting operational objectives. 

Note: 

Unused consumables may be considered 
accountable and recoverable. Generally; 
"consumables" does not apply to the wear out of 
system components. See EXPENDABLES. 

COSTING 

The process of determining the amount of resources 
that have to be expended or exchanged to acquire 
possession of, and or disposition control over any 
particular item or object at large: often based upon 
market analysis and cost-estimating-relationships, or 
CER's. 

CREW 

A generic reference to all personnel on board the 
Space Station or the Space Shuttle. 

CREWMEMBER 

Any one member of the crew. 

CUSTOMER 

Anyone who uses the facilities and services provided 
by the Space Station Program, but is not directly 
responsible for station or platform systems 
development, operations, or maintenance. Also 
referred to as a user. See USER. 

DISCIPLINE OPERATIONS CENTER (DOC) 

A user supplied location providing support to a 
discipline user group oriented towards a specific area 
of investigation wherein users could share technical 
interests and common overhead costs. A specific type 
of user operations facility that coordinates operations 
amongst local discipline users, or with other 
proprietary user operations facilities in same discipline, 
during flight preparation and execution . 

Note: 

Examples of user group disciplines include; 
materials sciences, life sciences, astro/solar/ 
planetary physics, commercial production, etc. 


DISTRIBUTED SYSTEMS 

An intricate network of pipes, cables, conduits, tubes, 
wires, and other components, that cariy electricity, air, 
water and other utilities and capabilities necessary for 
both station and platform operation and to allow the 
crew to survive and perform their roles and to serve 
the users needs. 

Note: 

Major distributed systems include: the 

environmental control and life support; guidance, 
navigation and control; propulsion; power; data 
management; communications and tracking: 
structures and mechanisms; fluids; and thermal 
management. 


DOCKING 

The coupling of two or more spacecraft in space. The 
process of establishing a physical connection between 
two spacecraft during which an exchange of 
momentum is employed to operate the attachment 
mechanism(s). 


ENCLAVE 

With reference to an operations concept where each 
international partner independently operates their 
respectively contributed elements of the Space Station 
Program; autonomy of operation by each partner; 
separation of roles and responsibility by partnership. 
Foreign territory surrounded by another, specified 
country. 


ENGINEERING SUPPORT CENTER (ESC) 

The engineering support centers will provide on-call 
and real-time consultation and sustaining engineering 
support, and the repository for the technical 
characteristics for the flight and ground systems 
hardware, during the development phases and 
operational phases of the program. 

Notes: 

• Initially, ESC*s will be located at the NASA and 
international partner's hardware development 
centers. 

• As operations mature, sustaining engineering for 
the U.S. orbital elements would be centralized at 
the Kennedy Space Center. 

• Sustaining engineering for the international 
partners orbital elements and all the program 
ground support systems and informations systems 
would remain distributed. 


EVOLUTION 

An addition of new elements, or new capability to any 
of the existing elements of the space station program 
or their systems, specifically after the development of 
the mature elements of the program. See also 
GROWTH. 


EXECUTION (OPERATIONS) 

Those activities that implement and operate the 
objectives described in the related strategy and tactics. 
Execution relates to the actual performance, 
enactment, or conduct of any operation - in real-time. 
Generally, a reference to "now" with respect to time 
in the operating environment of the program. See 
STRATEGY. 


EXPENDABLE LAUNCH VEHICLE (ELV) 

A ground-launched propulsion vehicle, capable of 
placing a payload into Earth-orbit or Eartn-escape 
trajectory, whose various stages are not designed for, 
nor intended for recovery or re-use. 

Notes: 

The final stage(s) of an expendable vehicle may 
remain in orbit with the payload(s) unless they are 
provided with special de-orbiting systems. 


EXPENDABLES 

Items or materials that are used during the course of 
an operational activity. Expendable items, when 
issued, are dropped from the property accountability 
system and are considered unrecoverable. See 
CONSUMABLES 
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EXPERIMENT 

That assembly of hardware, software, and operations, 
in space and on the ground that enables the user to 
meet the intended research objectives. 

Note: 

An experiment could include one or more payloads, 
delivered on one or more STS flights. Alternatively, 
one payload could encompass a number of 
individual experiments. 

EXTRAVEHICULAR ACTIVITY (EVA) 

Operations performed by crew members wearing 
space suits outside the habitable environment. 

FLIGHT 

The sequence of events that takes place between lift 
off and landing of STS Orbiter (or any aerospace 
vehicle). See MISSION. 

Notes: 

• The flight of a spacecraft such as the STS Orbiter is 
often divided into sub-parts (referred to as phases), 
e.g., powered flight, orbital flight (or on-orbit), re- 
entry, approach, landing, etc. 

• Because the operation of the Space Station is 
continuous, the term "flight" refers to on-board 
operations in space as well as those ground 
operations that are in direct support of the on- 
board operations. 

FLIGHT RULES 

Compilation of preplanned decisions designed to 
minimize the real-time analysis and decision process 
required when various situations occur. These 
decisions address both the existing on-orbit Space 
Station elements and those segments which are in 
transit to or from the Station. 

FRAMEWORK 

The recommended arrangement of selected concepts 
and options that demonstrates all the issues and 
principles considered by the Space Station Operations 
Task Force, and which meets all the cited objectives for 
the operations for the space station program. 

Note: 

The specific program objectives include: safe 
operations, fully supported user friendly operations 
and international participation, and due 
consideration of long term costs, evolutionary 
goals, and furthering science and technology 
development. 

GROUND (BASED) OPERATIONS 

Relating to activities or functions that are 
fundamentally formulated, planned, developed, 
controlled, executed, operated, and/or otherwise 
implemented on or from the ground. See SPACE 
BASED. 

GROWTH 

An increase in the capacity or capability of any of the 
existing elements of the Space Station Program or 
their systems; specifically after the development of the 
mature elements of the program. See also 
EVOLUTION. 

HEALTH MAINTENANCE FACILITY 

The in-flight facilities and equipment on-board the 
manned base capable of providing basic preventative, 


diagnostic, and therapeutic health care to the crew, 
commensurate with the level of on-board medical 
expertise. 

IN-SITU 

In the location where an object is situated. Particularly 
an object that is in space. 

INCREMENT (OPERATIONS) 

That period of time between STS missions to any of the 
Space Station Program Elements. For the manned 
base; from the launch of one Space Shuttle flight to 
the beginning of the next (ELV arrivals would be sub- 
sets within an increment). For platforms; from the 
launch (ground based or space based) of a space 
platform servicing mission to the beginning of the 
next. See TRANSFER (OPERATIONS), SPACE STATION 
OPERATIONS. 

Notes: 

• Each increment is initialized, and terminated, by 
the related transfer operations (launch to landing 
or return of the logistics or service mission). 

• Increments are contiguous, e.g.; the transfer 
operations occur within the end, and beginning, of 
the related increment. 

• Transfer operations may vary from a few days to 
weeks in duration. 


INFRASTRUCTURE 

All programs and projects with which the space station 
program must interface, and the processes and 
procedures by which the interfaces are operated and 
maintained. 

INITIAL OPERATIONAL CAPABILITY (IOC) 

A point in time in the contractual development of a 
project (e.g., the Space Station) at which the agreed 
upon, essential capabilities are operational for the first 
time. 

INTEGRATION 

The process of combining software elements, 
hardware elements, operations, networks, personnel, 
and procedures into an overall system or operation. 

INTERNATIONAL PARTNER 

Any of the non-U. S. partners participating and sharing 
in the design, development, and operation of the 
Space Station: National Research Council of Canada. 
National Space Development Agency (NASDA) - 
Japan. European Space Agency (ESA) 

INTRAVEHICULAR ACTIVITIES (IVA) 

Operations performed by crew members within the 
habitable environment. 

INVESTIGATOR 

Principal investigator or the delegated alternative. 

JAPANESE EXPERIMENT MODULE (JEM) 

The Japanese-provided laboratory module that is part 
of the Station baseline configuration. 

KIWI 

Series of development studies by the Atomic Energy 
Commission with the goal of developing nuclear 
reactors useful in high-thrust rocket engines. 
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Ku BAND 

A band of frequencies in the radio frequency spectrum 
extending from 12.5 GHz to 18.0 GHz. 

LABORATORY 

A pressurized module designed to support specific 
types of payloads, e.g., a life science laboratory or a 
materials processing laboratory. 


LIFE CYCLE COST 

A process and technique for predicting and 
considering the entire cost of a program or project 
from inception through to ultimate disposition. The 
process is important to understanding long-term 
impacts of decision-making early in the lifetime of a 
program. 

LOGISTICS 

The management, engineering, and support activities 
required to provide personnel, materials, consumables 
and expendables to the space station elements reliably 
and in a cost-effective manner. 

Notes: 

• Logistics management responsibilities include the 
definition, allocation, scheduling, and control of 
equipment, personnel and process resources, and 
flow. 

• Logistics engineering functions include equipment 
and process requirements definition, coordination, 
integration, and implementa-tion. 

• Logistics support functions include provision-ing, 
storage, repair maintenance, and transportation of 
all station system parts, replacement units (ORlTs), 
payload carriers and operational support person- 
nel. 

• The overall space station logistics network is 
referred to as the Integrated Logistics System (ILS). 

LOGISTICS OPERATIONS CENTER (LOC) 

Facilities and resources located at the launch site that 
manage, provide, and support all the required logistics 
operations and services for the station system. 

MAINTAIN 

To keep in existence or to keep in a certain condition. 
Specifically relating to the Space Station systems. See 
SERVICE/SERVICING. 

Note: 

• Maintain and maintenance relate specifically to the 
Space Station systems operations. Service and 
servicing relate to the users equipment and 
systems. Service is to the user as maintain is to the 
space station system. 

MAINTAINABILITY 

The ability of the space station systems to be 
maintained. The probability that an item can be 
restored to or retained with acceptable performance 
limits. See MAINTENANCE. 


MAINTENANCE 

The task of keeping things in existence or in a certain 
condition. The execution of all the necessary actions 
to retain or restore the space station systems within 
their specified performance limits. See MAINTAIN. 
Notes: 


• The frequency, magnitude and complexity of any 
maintenance, or the required level of maintenance, 
is described by the conditions to be met. 

• To be maintained, an object must be maintainable 
or have the facility for maintainability; the level of 
maintainability must equal or exceed the required 
level of maintenance. 


MANIFESTING 

The process of defining what materials will be 
physically exchanged between the ground and space 
elements of the program, and when and how those 
transfers will be scheduled and implemented. 

MANNED BASE 

Major, manned element of the Space Station Program 
providing permanent manned presence in space. The 
manned base includes all the U.S and partner provided 
manned elements and ail the related systems and 
structure. 

MATURE OPERATIONS PHASE 

The continuous period of activity commencing with 
the establishment of that configuration of the Space 
Station that provides a permanently manned 
capability in space, and continuing there after 
throughout the lifetime of the program. Mature 
operations will embody the management and 
operation of all subsequent growth and evolution. 

MISSION 

A mission generally refers to the sequence of events 
that must take place to accomplish some prescribed 
objective(s). 

Notes: 

• One or more mission can be accomplished in one 
flight of the Space Shuttle, or one mission can 
require two or more Space Shuttle flights. 

• Any one shuttle flight can execute several 
concurrent missions, some in part and some in 
whole. 

• The Space Station, including the space platforms, 
may implement and execute on-board activities as 
a series of missions (occurring serially or in parallel), 
each mission relating to a prescribed payload or on- 
orbit activity. 

MISSION SET 

The complement of payloads that is onboard the 
Manned Base or a Space Platform at any given time. 

MODULE 

Major elements of the Manned Base including: The 
Habitability Module, U.S. Laboratory Module, 
Japanese Experiment Module, and the Columbus 
Module. 

ORBITAL MANEUVERING VEHICLE (OMV) 

The unmanned propulsive stage used to ferry between 
the station or shuttle and a platform or free-flyer. It 
will be used either to bring the spacecraft to the 
Station or shuttle for servicing or to perform servicing 
in-situ via a smart front end. 

ORBITAL REPLACEABLE UNIT(ORU) 

The lowest level of component or subsystem hardware 
that can be removed and replaced on location under 
orbital conditions. 
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PARTNER 

International partner. SEE INTERNATIONAL PARTNER. 


PAYLOAD 

An aggregate of instruments and software for 
performance of specific scientific or applications 
investigations, or for commercial production. A 
specific complement of instruments, space equipment, 
and support hardware carried into space to accomplish 
a mission or discrete activity in space. 

Notes: 

• Payloads may be internal to pressurized modules, 
attached to the station structure, attached to a 
platform, or they may be free-flyers. 

• A payload may be designed to be re-used either by 
return to the Earth's surface for refurbishment and 
re-launch, or by applied in-space services. 

PAYLOAD OPERATIONS 

Those ground based and space based activities 
associated with the strategic, tactical, and execution of 
plans, preparations and procedures to deliver a 
payload to its destined location, exercise the payloads 
capabilities on location and, as required, return or 
deliver all or part 

of that payload to its final destination. 

Note: 

• User payload operations are usually undertaken by 
the user, the users non-program agent, or assigned 
program personnel under a resource assignment/ 
allocation/refurbishment basis. When undertaken 
by Program personnel, user payload operations are 
usually referred to as servicing operations, or 
service operations. 

• Station, or system, payload operations are usually 
referred to as maintenance operations, or engine- 
ering operations. 

• Station or system payload operations are usually 
undertaken by program personnel. 

PAYLOAD OPERATIONS INTEGRATION CENTER (POIC) 

The payload operations integration center is a station 
program supplied facility to integrate user payload 
operations activities into the manned base. Similar 
functions for platforms are embodied in a platform 
support center (PSC). The POIC provides the focal 
activity for the distributed user operations facilities to 
develop an integrated user operations execution plan 
on an increment-by-increment basis, and supports the 
real-time management of in-flight departures from 
those plans. 

PERMANENT MANNED PRESENCE 

That point in the development and operation of the 
Space Station Program where the configuration of the 
manned base is capable of supporting man's presence 
on a continuous basis with only the incremental 
presence of the Space Shuttle Orbiter. 

Notes: 

• The capability to provide permanent-manned- 
presence does not mandate continuous manning 
(or permanent manning) which is, nonetheless, an 
inherent capability within the provisions of a 
permanent manned capability. 

PLATFORM 

See Space Platform 


PLATFORM SUPPORT CENTER (PSC) 

Platform support centers combine system and user 
support functions to provide for operations 
management and sustaining engineering for the 
platforms. Operations management can extend to 
interfaces with other platform user operations centers 
and facilities, and can include the planning and 
controlling of platform payload operations (mission 
objectives, including remote telescience) and platform 
transfer operations (service objectives) - except when 
the co-orbiting platform is within a zone controlled by 
the manned base. 

Note: 

• Two PSC's are considered in the recommended 
framework; one at GSFC for the U.S platforms (POP 
and COP), and one in Europe for the ESA platform 
(POP). 


POLAR ORBIT PLATFORM (POP) 

See SPACE PLATFORM 

PRICING 

The process of determining the charges to be levied 
upon the users for accommodating their experiments 
and for other services as rendered; based upon actual 
costs and cost sharing agreements amongst the U.S. 
and the international partners. 


PROXIMITY OPERATIONS 

Activities relating to mission and flight control 
operations that take place within the proximity 
(approximately 1 Km) of the space station. The 
operation of one or more spacecraft within the vicinity 
of another, with the relative positions stabilized and 
the rate small enough to preclude the requirement for 
re-rendezvous. 

QUALIFICATION 

See VERIFICATION 


REAL-TIME 

Defines a system response with the smallest, practical 
time delay taking computational processing, required 
communications, and associated I/O activities into 
account. Essentially; - now. 

REAL-TIME SUPPORT 

Operational support functions which are provided 
(and executed) while a mission is in progress. 

REGIONAL OPERATIONS CENTER (ROC) 

A partner supplied, geographically focused location 
providing support to regionally based user groups 
wherein users could share common overhead costs or 
technical interests. An ROC includes facilities that can 
support user operations integration functions such as 
coordinating operations amongst local users, discipline 
centered users, or with other proprietary user 
operations facilities during flight preparation and 
execution. 

S-BAND 

A band of frequencies in the Radio Frequency 
spectrum from 1.55 GHz to 5.2 GHz 
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SCENARIO 

Hypothetical, structured example. An enactment or 
presentation of one possible set of events, often from 
amongst many other possibilities. 

SERVICEABLE SATELLITE 

A satellite designed to be provided with some degree 
of servicing in space to re-establish or sustain its 
mission capability. 


SERVICING 

To keep in existence or to keep in a certain condition. 
Specifically relating to the Users space equipment and 
systems. See MAINTAIN and MAINTENANCE. 

Note: 

Maintain and maintenance relate specifically to the 
Space Station systems operations. Service and 
servicing relate to the users equipment and 
systems. Service is to the user as maintain is to the 
space station system. 

SPACE (BASED) OPERATIONS 

Relating to activities or functions that are formulated, 
planned, developed, controlled, executed, operated, 
and/or otherwise implemented in space, particularly in 
association with the Space Station. See GROUND 
BASED 

SPACE PLATFORM 

An unmanned, orbiting, multi-use structure, capable 
of supplying utilities to changeable payloads, 
dependent upon the Space Station or the Shuttle for 
its long-term operation. 

Notes: 

- The recommended framework assumes a baseline 
of three platforms for the initial Space Station 
Program: Two U.S. platforms; one (POP) in polar 
orbit and serviced from the NSTS, and one (COP) co- 
orbiting with and serviced from the Space Station; 
and one European platform in polar orbit. 

SPACE STATION 

The term Space Station, Space Station Program, and 
Station should be interpreted as global terms,each 
referring to all of the components of the program, 
both in space and on the ground. Components of the 
program include the Manned Base, the Co-Orbiting 
Platform, the Polar Orbiting Platform, the Orbital 
Maneuvering Unit, and the ORUs. See SPACE STATION 
PROGRAM, STATION. 

SPACE STATION OPERATIONS 

All program wide, space based and ground based 
activities required to operate the Space Station 
Program Elements. 

Notes: 

• Space Station Program activities are a series of 
mission increments for both the manned base and 
the space platforms, each increment including the 
plans for a series of on-orbit operations and 
payload execution. 

SPACE STATION PROCESSING FACILITY (SSPF) 

A facility in the vicinity of the STS launch operations 
that houses the prelaunch processing activity for ail 
space station hardware destined to orbit, and all 
prelaunch and post flight logistics turn-around 
processing, including payload racK-to-station interface 
verification, checkout, and certification for flight. 


SPACE STATION PROGRAM 

The aggregation of U.S. and international partner 
space projects, space craft, space systems, and ground 
systems generally associated with the development 
and operation of, and encompasses within the 
interface specifications for, a permanent Manned 
Base, Space Platforms and an Orbit Maneuvering 
Vehicle, and whose development and operation and 
funding are managed by NASA and the international 
partners. 

SPACE STATION SUPPORT CENTER (SSSC) 

The SSSC provides centralized systems management 
and control for the manned base, including the 
elements provided by the partners, and has the safety 
responsibility for the crew and manned base. The SSSC 
also approves the integrated plan for user and systems 
activities based on the criteria for overall systems 
integrity, crew operations effectiveness, and crew 
safety. The SSSC monitors the systems status of the 
manned base, relays commands to support general 
systems operations and insures that safety 
requirements are met. Crew training facilities are 
closely associated with the SSSC. 

SPACE SYSTEMS 

Those Program-provided, distributed or element- 
unique orbiting systems whose safe and predictable 
operation is fundamental to the safety of the crew, the 
integrity of the manned base or platforms, for the 
effective utilization of manned base or platform 
resources. 

SPACE TRANSPORTATION SYSTEM (STS) 

The Space Shuttle fleet, and all the related ground 
based facilities and equipment. 

STS CREW 

Those personnel whose primary responsibility is the 
operation of the Orbiter. Does not include Station 
personnel in transit onboard the Orbiter as passengers. 

STRATEGIC (OPERATIONS) 

Those functions concerned primarily with establishing 
and coordinating policy and objectives. See STRATEGY 

STRATEGIC (PLANNING) 

That planning that leads to approval of a mission; that 
process required to define the combined plans for the 
platform/station/ payload, and transportation 
missions. See STRATEGY. 

STRATEGY 

The science of directing large scale program 
operations. Maneuvering into the most advanta- 
geous position prior to an engagement. 

Notes: 

• In general, strategy and tactics are associated with 
"planning" and aoing" and, as a set, can be 
applied to circumstances in many different time 
scales; similarly structured sets of strategy and 
tactics can be "nested" (in the computer software 
sense) so that accomplishment of any major 
objective can involve a hierarchy of strategy and 
tactics. 

• The terms execution and engagement are often 
used to relate to specific accomplishment and 
achievement within the framework of tactics. 

• In the military context; strategy (plans and 

planning) precedes tactics; tactics (the enemy is in 
sight) precedes engagement: engagement 

implements action. 
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• The OTF has applied "strategy" and "tactics" in 
fairly specific connotations: strategy (more than 
one to two years before the event) precedes tactics; 
tactics (up to two years before the events, down to 
the event itself) precedes execution; execution 
implements the event). 

SUSTAINING ENGINEERING 

Sustaining engineering is performed at the 
Engineering Support Centers at the launch site and/or 
the development center. The engineering encompas- 
ses analytical and technical services as well as 
management and training services and operations. 
The Space Station operations framework recognizes 
three general types of sustaining engineering: flight 
systems maintenance engineering performed at the 
launch site and development center and development 
centers on space systems and ORU hardware; flight 
systems design engineering performed at the 
development centers on assigned space systems and; 
payload integration engineering performed at the 
launch site or development site on program approved 
payloads. 


TACTICAL (OPERATIONS) 

Those functions concerned primarily with using the 
established strategy, policy, and objectives to produce 
plans and direction for tneir accomplishment. See 
STRATEGY. 

TELESCIENCE 

A mode of space based scientific investigation, 
including operations and analysis, that is executed 
remotely from the principle location of the associated 
equipment. Ground-based users may interact directly 
with real-time command and control operation of the 
space-based equipment in response to real-time 
observed data. 

Note: 

• Depending upon the degree of sophistica-tion, 
telescience operations may be enhanced by 
incorporating telepresence as one of many features 
of advanced teleoperations. 

• Teleoperations encompasses any remotely 
managed activity, with or without feedback of 
operations data to allow a local operator to 
interact with the remote activity. 

• Telepresence is a level of sophistication in tele- 
operations where the operator receives sufficient 
sensory information from the remote location 
(mono/stereo video, audio, tactile, etc.) to be able 
to create a high resolution image of the remote 
location within which the local operator can 
experience a physical sense of presence at the 
location of the investigation. 

TRAFFIC MANAGEMENT ZONES 

Specified regions around the Space Station that define 
the operational boundaries for proximity operations, 
station command and control, departure, rendezvous, 
co-orbiting satellites, non-co-orbiting satellites, and 
parking orbits, etc. 

TRANSFER OPERATIONS 

A period of time during which the manned base is 
involved with the arrival and departure of an STS 
enabled logistics type mission, or the platforms are 


involved with an OMV enabled logistics type mission, 
each providing equipment transfer and installation. 
Notes: 

• The manned base transfer operations period 
extends from prior to STS arrival (while equipment 
is being prepared for return to earth), to sometime 
after STS departure (while equipment is being 
installed). 

TRANSPARENT TECHNOLOGY 

A system component is said to represent 'transparent* 
technology if the component can be replaced by a 
component based on a different technology without 
affecting the rest of the system. 

UNMANNED PLATFORMS 

See SPACE PLATFORMS. 

USER 

Any organization, group, or individual who uses or 
plans to use the Space Station or any other Space 
Station Program Element as the vehicle for the 
operation of a payload or related mission. See 
CUSTOMER. 


USER OPERATIONS FACILITY (UOF) 

User operations facilities are built and operated by the 
user as best suit the needs associated with the payload 
operations and the experiment objectives. The 
facilities can be equipped to support personnel and 
equipment involved in payload operations, to monitor 
and control experiments, transmit payload commands, 
and storing and analyzing data products from the 
station. 

Note: 

• User operations facilities may operate as 
independent interfaces to the program, through 
the payload operations integration center (POIC), 
or they may be affiliated with discipline operations 
centers (DOC's) or the regional operations centers 
(ROC's). 

UTILIZATION 

A broad program aspect of the Space Station Program 
associated with the beneficial use and utility of the 
Space Station Program Elements. 

Notes: 

• Utilization encompasses the process of identifying 
Space Station users and customers, defining, and 
refining their requirements for space services and 
capabilities, integrating these requirements into 
the Space Station Program as interface hardware, 
software, and procedures. 

• Utilization encompasses this role for the initial 
Space Station and throughout the evolutionary 
growth. 

VALIDATION 
See VERIFICATION 

VERIFICATION 

The process of proving circumstances to be true or of 
being well grounded. 

Notes: 

• "Certification", "Qualification", "Validation", and 
"Verification" are used extensively in the OTF 
documentation. 
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• In general, certification and qualification tend to 
deal with qualities: CERTIFICATION emphasizes 

properties that are attributable to a product or 
person; QUALIFICATION tends to emphasize the 
requirements that a product or person must have 
to meet an application. 


• In general, validation, and verification deal with 
assurance and confidence in assertion, they tend to 
endorse the accuracy and truth in the certification 
and qualification process: VALIDATION tends 

towards repeated assertion that conditions of truth 
are evident; VERIFICATION tends towards proving 
or reproving a fact to be true, such as testing to 
demonstrate capability. 
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